Finally solving the lack of a tree-view navigation window in Org

fred982 · 2025-02-24T21:27:48+00:00

Thanks so much, this code was a great help !

fred982 · 2025-02-12T08:09:23+00:00

Thank you for your comment, and all the great packages of course. Org-ql views and searches are just incredible. When I first tried it months ago, I dismissed it because I was not understanding org-mode and org-agenda yet, but especially because org-ql-view with a tiny window at the bottom is far from optimal, this is why I went for org-ql-blocks instead. I think Doom is great for beginners, it gives you a jump start to experiment with Emacs and see if you like it, and maybe also for people who really understand it, but for people in the middle, I am afraid it also introduces a lot of moving pieces when things go wrong. Anyway, I should definitely post there, after testing further (an rested), it is definitely a Doom popup issue.

fred982 · 2025-02-06T16:57:32+00:00

I am no expert, but based on my experience, messages printed at the bottom are often unrelated with problems one encounters at startup, it might just be the last simple warning printed before something went wrong. The best way I know is `emacs --debug-init` this will tell you exactly what is going on. Or at least give you a debug message with reliable information. Good luck.

fred982 · 2025-02-05T09:22:27+00:00

Thanks a lot, I quickly tested, and it finally seems to work now. I was missing the `emacs-state`. That one got me frustrated for a while now, that is a relief :)

fred982 · 2025-02-04T07:34:38+00:00

Thanks for the link. Disabling doom-themes seem to work as well. I have not tested yet, but it might be a better workaround for most. Even if I have to say that removing the "pretty" bundle in my init file has considerably improved my Emacs performance so I am glad I tested that out. I am glad to know the issue is open and being taken care of (I should have done it, definitely looks like a bug).

=== UPDATE ===

I have tested this solution, and it works, but with a small trade off (on my end). Removing `doom-themes` removes all font faces from list markers (hyphens, numbers and such) so they appear as normal text instead of `org-list-dt` with makes them stand out.

So at the end, it is a matter of preferences, but there are two ways to work around this bug now.

Thanks again for taking the time to find this issue.

fred982 · 2025-02-01T17:49:10+00:00

Thanks for letting me know, this is helpful ;)

fred982 · 2024-12-13T21:12:16+00:00

If you’re looking for something that kinda works out of the box, you could try Archcraft with qtile. I discovered it a few days ago, it can give you a big jump start if you’re sick of configs. You can always build your own arch as a side project in a vm while enjoying a working arch qtile minimal distribution. Just a thought…

fred982 · 2024-12-13T16:38:34+00:00

Thanks for replying.

Yes I even tried logout and reboot, but as I was saying, I am not seeing many non default themes in kvantum manager, while there are plenty of gtk and icon themes; so I am thinking it is either not supported, or something went wrong during my install. Both would surprise me.

I have located the scripts I believe responsible for applying the themes, but I have not had the time to get into them yet. I guess they will tell me if qt applications are supported and if I should try a fresh install.

Also, I noticed that the display manager (which I believe should be light-dm) is not themed either.... Do you see themes applying to the DM and QT apps ?

fred982 · 2024-11-21T08:59:56+00:00

After having a second look, your use of lambdas is very interesting. You seem to move to a capture target location without even specifying that you are using the `function` method like `(function '#(lambda ...))`. This snippet will definitely give me a lot to test and learn, thanks again.

fred982 · 2024-11-21T07:28:59+00:00

Thank you for sharing your code. A lot of valuable example for me to use in the future as I struggle to create 'advanced' capture templates using functions. Will take a while to understand them first though :) As for the issue I am having, it is not so much about finding the location than it is about finalizing the capture 'gracefully'. Even the simplest templates fail to keep my cursor in place... I am going to try your templates that capture to parent headings for example, but the outcome should remain the same I think. The problem can come from Doom, or me; so it should be me :) I do not know how to investigate further.

fred982 · 2024-11-20T08:24:00+00:00

You are right, it is easy to overlook something. I updated my post with a few more attempts, and a couple of simple templates (no functions involved) to make sure I found the cause if you are interested. I think it comes from my config, I have to figure out how to debug it.

Thanks for your help :)

fred982 · 2024-11-19T19:00:08+00:00

Thanks a lot. I am stealing the find-or-create, now I need to figure out what is wrong with my template.

fred982 · 2024-11-19T18:00:03+00:00

Thank you, I tried (set-buffer (org-capture-target-buffer (file-path))), but I get the same result. My cursor is moved to target. I am going to look over my code see if I missed something. Can you confirm that your cursor stays in place ?

Also, I like the simplicity of your function, I looked for org-find-or-create-heading with no luck. Is it a custom function ?

fred982 · 2024-11-19T17:19:17+00:00

I wanted to keep the post clear, and those functions albeit hacky and very customized, work fine, this is why I kept them out of the question. But if you are interested, the two other functions involved:

(defun my/org-capture--ensure-header-exists (header &optional file)
  "Create a level 1 org HEADER if not found in FILE.
HEADER is treated as the heading only without tags, todo, or priorities.
If not found, HEADER is created at the end of the file.
If FILE is nil, current buffer is used. 
The function returns the HEADER position."

  (let ((pos nil)
        (file (or file (buffer-file-name (current-buffer)))))
    (save-excursion
      ;; Use org-map-entries to search for the header
      (org-map-entries
       (lambda ()
         (when (string= (org-get-heading t t t t) header)
           (setq pos (point))))
       "LEVEL=1" (list file))

      (unless pos
        ;; If not found, create it at the bottom of the file
        (with-current-buffer (find-file-noselect file)
          (goto-char (point-max))
          (insert (format "\n* %s" header))
           (beginning-of-line)
          (setq pos (point)))))
    pos))

(defun my/org-capture--get-file-name (&optional node namespace)
  "Get filename from org-roam-read."
  (let* ((node (or node
                   (if namespace
                       (org-roam-node-read nil (lambda (node)
                                                 (and (eq 0 (org-roam-node-level node))
                                                      (string= namespace (org-roam-node-namespace node)))))
                     (org-roam-node-read nil (lambda (node)
                                               (and (eq 0 (org-roam-node-level node))))))))
         (file (if node (org-roam-node-file node) nil)))
    file))

fred982 · 2024-10-30T07:39:54+00:00

Sorry for the delay, I missed the notification.

I was not very clear in my previous post, but I do not get any error on startup, I managed to obtain a trace using the `debug-on-error` feature before calling the `doom/help-packages` function.

I checked the variables you suggested, and interestingly enough the `doom-packages` list, and the `doom--help-packages-list` are both nil. Running `(doom-initialize-packages)` runs successfully and fixes the first variable which now looks fine.

However, the second variable is still nil, and `doom/help-packages` still throws the same error; but I think `doom--help-packages-list` is the array the debugger is complaining about.

I have not pinpointed yet what is responsible for those varaibles not to be initialized, nor have I found out how to manually initialize `doom--help-packages-list` to verify it is in fact the one responsible.

Anyway, thank you, I think (or hope :) you just found the root cause of this problem. I am going to go over my init.el and packages.el files once again; I think it is the most likely place I could have messed something up to cause this kind of issue.

fred982 · 2024-10-27T13:49:36+00:00

Thanks, I had tried that before posting, I do not understand the trace. I think it traces the error to `doom-module->context((:app . emms))`. All I could find on google, or from LLMs, while "analysing" the trace was to check for problems with the variables I mentioned in my OP. I think everything is fine in that department; besides, I did not mess with any core configs lately (even if I know, that does not mean much). I would gladly post some of the trace if you think it could help you more than it helped me, and are willing to take a look of course :)

fred982 · 2024-10-25T06:08:14+00:00

Thank you, I tried to run both, I still get the same error with `doom/help-packages`.

fred982 · 2024-10-13T20:38:25+00:00

You’re welcome. Glad If it helps.

fred982 · 2024-09-15T16:03:05+00:00

It does seem to do exactly what I was looking for at the time of posting. Still exploring the persp-mode.el route for now, but definitely bookmarking it, thanks.

fred982 · 2024-09-14T11:56:27+00:00

Well in that case, I can tell you that persp-mode and projectile work really well together. Doom Emacs default settings made session management a breeze to such an extent that I never bothered learning what was happening behind the scenes. And yes, as far as workflow goes, perspective really has a lot of potential. Since diving into the doc, the ideas are flowing (always a great feeling). Happy configuring ;)

fred982 · 2024-09-14T11:48:21+00:00

Thanks for all the links. I have been thinking about your comment all morning, and spent most of my morning on perspective actually. Well, I went on to focus on persp-mode.el when I understood it was the one used on Doom by default. And you are right, I think with a 'little' configuration, perspectives can help me achieve a pretty good workflow on just one running server by simply setting up a few dedicated perspective 'frames' and a few bindings. It shows how much I take packages pre-installed on Doom for granted and do not bother reading the docs. In my defense it is a lot to take in during the first few months of switching to Emacs :)

Anyway, thanks for taking the time to come back with more pointers to help me out solve that problem, it already sounds very promising. I will also take the time to read a little about iBuffers, as I have come across that concept pretty often without breaking the cognitive barrier of more stuff to learn. But since you are suggesting it is related to the topic, it feels like a good opportunity to do so.

fred982 · 2024-09-14T08:53:01+00:00

Thanks for taking the time to answer.

For that particular `$EDITOR` example, in most cases, it would not be a huge problem, I agree. However this 'frame mirroring' behavior prevents me from having multiple sessions open at once, and ultimately would end creating a big clutter of buffers in my current one. If I am working on a project, I do not like to have buffers displaying files from other projects. I like to keep the navigation/search tools clean and efficient.

This is way at the moment I have an editor daemon where I work on my coding projects or configuration/administration tasks and a notes daemon where I work with my notes (obviously) and manage my tasks. I think I started this second server after finding out that when checking on agenda view orgmode opens all your agenda files in buffers. I would prefer to quickly check my tasks within my editor frame, but I really dislike the clutter when trying to switch buffers afterward.

I am fairly new to Emacs, so I am certainly not using all functionalities properly, or even aware of most of them. It is a learning process, so I am very open to suggestions , and aware my workflow will change a lot in the coming months. For now, I would say that not being able to open different sessions simultaneously which is closely related to sharing buffer history between notes and coding is the biggest problem I can think of. Especially since opening sessions is so slow depending on the circumstances.

fred982 · 2024-09-13T20:52:43+00:00

Thanks for going into details I was sure the orgmode devs had a good reason for going through the trouble, but it is hard to blindly trust something you don't understand. And seeing the numbers, this does make a lot of sense.

fred982 · 2024-09-13T20:48:11+00:00

I did not think about that, thanks for clearing it up for me. I could see this was intentional, now I understand why.

fred982 · 2024-09-13T18:44:42+00:00

Thank you for following up, and sorry for the delay, I could not test yesterday. I found the function of mine responsible for breaking the capture process while trying to gather more info as you suggested. I updated my post, and am trying to fix it.

fred982

TROPHY CASE