Sidebar "roam buffer" gets replaced with org-roam node instead of updating

Troubleshooting
1

I love org-roam!

In spacemacs (using org-roam v2), I open a “roam buffer” sidebar with org-roam-buffer-toggle, which gives me the window with the backlinks on the right half of my frame – the left half containing the current org-roam node I’m looking at.

When I then hit RET on a link in the roam buffer sidebar on the right, that window changes to show the linked node I just navigated to instead of the roam buffer sidebar. The old node I was looking at is still there on the left. I expected it instead to replace the currently shown node in the window on the left with the linked node I just navigated to – so that the sidebar would just stay in the same place forever while the current node on the left updates as I navigate.

I tried in doom and for me it doesn’t replace the “roam buffer”, but seems to open a new window so I have three the first time I click on something in the sidebar (roam buffer sidebar on the right, old node top left, new node bottom left).

Looking at the definition of org-roam-node-visit and edebug-defuning, I’m a little surprised that it ever does anything other than replace the sidebar with the new node if you just hit RET: pop-to-buffer-same-window gets used both in spacemacs and doom, and that function as I understand it is supposed to replace the current window (i.e. the sidebar), if possible. To be honest I’m scratching my head why anybody would ever want to replace the sidebar with the new node, either, but hey emacs users are a varied bunch.

I found I had to do this to get it to work as I expect:

(defun my-org-roam-node-visit ()
  (interactive)
  (org-roam-node-visit (org-roam-node-at-point t) t t))
(define-key org-roam-node-map [remap org-roam-buffer-visit-thing] 'my-org-roam-node-visit)

Digging a bit further in the emacs docs (for pop-to-buffer-same-window), I think it might be that I’m supposed to “dedicate” the sidebar window to the roam buffer? It took me a very long time to get there! Seems like this would be a good thing to document? I’m still not sure exactly how I should configure this. Even if I did that, I’m not sure I’d get what I expected (maybe I’d get a third window like I got in doom?).

Incidentally, “roam buffer” seems not ideal as a term, since you might expect that to refer to any org buffer that you use with org-roam, not to the sidebar specifically. But that seems to be the only term that org-roam defines to refer to this functionality?

2

How the org-roam buffer is displayed can be configured by built-in configuration and documented with an example in this par of the manual. There is some more examples on the wiki, too. You should not have to redefine functions (though that’s also a legitimate way).

Or maybe I didn’t understand your intention / issue.

3

Thanks, I should have mentioned that. I think that was the first thing I tried, but I tried so many things after that that I forgot about it :slight_smile:

The “sidebar” example from the manual doesn’t work for me. It’s only after digging into it and finding out what I wrote above that I found that the window has to be dedicated to the buffer – and in fact for me it’s not dedicated ((window-dedicated-p (get-buffer-window "*org-roam*")) is nil), despite the documentation of display-buffer-in-side-window which seems to say otherwise (but I don’t know much about window.el so maybe I’m misinterpreting that).

I’m not sure why the window doesn’t get dedicated – maybe I’ll dig further another day to see why. I’m using a rather complicated emacs configuration right now – something in there might perhaps be causing that. However, that’s because earlier I tried a vanilla out-of-the-box spacemacs config, and that actually behaved worse: the org-roam buffer didn’t display correctly and RET on a link didn’t cause anything to happen except to trigger a message, as other spacemacs users have reported elsewhere, without a clear cause so far that I can see. For some reason my more complicated spacemacs config doesn’t tickle that problem so I abandoned the usual “start with a simple config if nothing works” principle.

Incidentally, in case it helps somebody else (I wasn’t able to guess what was wrong and had to bisect my emacs config to find it), this example, which I think I got from this forum, broke ivy for me. ivy would not show any completion candidates, just the completion count:

(add-to-list 'display-buffer-alist
             '("\\*org-roam\\*"
               (display-buffer-in-side-window)
               (side . right)
               (slot . 0)
               (window-width . 0.25)
               (preserve-size . (t nil))
               (window-parameters . ((no-other-window . t)
                                     (no-delete-other-windows . t)))))

I’m guessing it’s the preserve-size that caused the trouble there but I haven’t checked carefully.

I knew the Roy Castle principle applied to emacs, but not quite so literally (sorry in joke for people in the UK and of a certain age I guess).

4

It’s probably the long-standing Spacemacs issue. clicking on any link within *org-roam* buffer fails with an error message · Issue #1732 · org-roam/org-roam · GitHub.
Turning off page-break-line-mode globally seems to solve it.

(global-page-break-lines-mode 0)
1 Like
5

Thanks, I somehow didn’t try using the global-* function as that suggests – I guess having tried disabling it with page-breaks-line-mode and distracted by the final comment on the spacemacs issue in which one person finds even globally disabling it didn’t work for him.

Perhaps worth noting for wandering searchers also that (as the org-roam issue you cite says), that should go somewhere like dotspacemacs/user-config. That’s kind of the usual place, except that I found that putting my (setq org-roam-v2-ack t) there was apparently too late: that works for me at the very top of my spacemacs .init.el, but not in my dotspacemacs/user-config – but with (global-page-break-lines-mode 0), it’s the opposite. Finding exactly what time to run your initialization is a perpetual problem of configuring a maximally dynamic and customizable environment like emacs…

6

I came back to this because I found that sometimes when point was at a link in the org-roam buffer (sidebar, for me) RET would be bound to org-open-at-point, which would cause the link to open in the sidebar. I’m not sure why (and in fact right now I can’t find a link like that), but that motivated me to drop my rebinding of org-roam-buffer-visit-thing and figure out how to dedicate the sidebar ((dedicated . t) below):

    (add-to-list 'display-buffer-alist
                 '("\\*org-roam\\*"
                   (display-buffer-in-side-window)
                   (dedicated . t)
                   (side . right)
                   (slot . 0)
                   (window-width . 0.33)
                   (window-parameters . ((no-other-window . t)
                                         (no-delete-other-windows . t)))))

Haven’t been using that long but seems to work so far.

1 Like
7

I also do not understand the behavior of the org-roam-buffer. I want that when I hit RET on a backlink, it would open in the main buffer on the left (as was in V1).
The configuration above, and in the documentation do not give this behavior.
How can I accomplish this?

8

Try this. Works on my end.

  ;; Get `org-roam-preview-visit' and friends to replace the main window. This
  ;;should be applicable only when `org-roam-mode' buffer is displayed in a
  ;;side-window.
  (add-hook 'org-roam-mode-hook
            (lambda ()
              (setq-local display-buffer--same-window-action
                          '(display-buffer-use-some-window
                            (main)))))
1 Like
9

OMG, that is wonderful!!
Thank you so much!

Perhaps you would be able to help with another minor thing.
I want the org-roam-buffer window to take less space in the total-window of emacs.
Right now it takes half of the space. I would like to be similar to V1, when it took ~0.3 of the space.

I have this in my config

  (add-to-list 'display-buffer-alist
               '("\\*org-roam\\*"
                 (display-buffer-in-side-window)
                 ;; (dedicated . t)
                 (side . right)
                 (slot . 0)
                 (window-width . 0.25)
                 (preserve-size . (t nil))
                 (window-parameters . ((no-other-window . t)
                                       (no-delete-other-windows . t)))))

which I thought should set it to 0.25 of the width, but it does not work…

10

When you open org-roam-buffer, what’s the buffer name displayed in your mode line? The first line of the config is a regex; it needs to match the name of the buffer. I suspect Doom does something to change the buffer name.

11

The first line is the name of the note (i.e. the name of the file).
Isn’t this what it should be?

12

No. I am on my phone so can’t show you. It’s right above the minibuffer. Name of the buffer.

It’s for the side-window, not your note. By default, it should be *org-roam*.

13

This is what I have at the bottom of the window

Screen Shot 2021-11-20 at 14.40.01
Screen Shot 2021-11-20 at 14.40.011898×66 9.43 KB

It says *org-roam* on the right part (which is the org-roam-buffer).
Is this what you refer to?

14

Yes. Your code works for me. I just copy-and-pasted it to my configuration file.

For you, it’s probably either Doom getting in the way, or you put this piece of code that’s not evaluated before the toggle. If you manually evaluate it, does it work?

Screenshot from 2021-11-20 15-57-51
Screenshot from 2021-11-20 15-57-51986×619 41.2 KB

15

You are right! for some reason this piece of code is not evaluated on startup. If I just evaluate it, the org-roam-buffer adjusts.

I am not sure how to fix it…
Maybe it’s a doom issue.

16

What is its value before manually evaluating add-to-list but after org-roam?

I have a feeling that some module of Doom does setq instead of add-to-list to override what you do in your configuration.

On a side note…

My sincere suggestion is to not use Doom. I moved back to vanilla because I felt I was spending too much time learning Doom than Emacs itself and fixing breakages after ‘doom sync’ (for modules I didn’t know I had or Straight).

I used to use only a handful of doom modules. I have never looked back. If you program in Emacs, then you might have a good case to keep Doom. Otherwise moving out of it is a valid option.

1 Like
17

Thanks very much for the tip:) I am quite a beginner in emacs. So I am a bit afraid to move out of doom. But I will consider.

Anyway, I got some help from discord, and this issue is finally solved!
This is the code:

(after! popup
  (set-popup-rule! "\\*org-roam\\*"
    :side 'right
    :width 0.33
    :slot 0
    :parameters '((no-other-window . t)
                 (no-delete-other-windows . t))))
1 Like
18

As far as I can see, all this is Doom specific. It’s good that Doom community supports other users like this. I stand by my suggestion but there is no need to hurry.

It’s also really good to know that Doom has its own windows management system. There have been multiple issues in this Discourse on side-windows. I could never help Doom users; now I think I could direct these questions to Doom’s popup module.

Thank you!

1 Like
19

@roi.holtzman

Sorry, INSTEAD of this complex stuff, I just made the same thing work by customizing this variable:

(setq pop-up-windows nil)

I don’t know if it works in the same way in Doom but it may be worth a try.
The add-hook solution earlier is a bit of “hacky” – and not necessary on my end.

1 Like
20

This works well!!

(disclaimer - I have two machines running emacs, and for some reasons one of them has a lower version of doom. I don’t know why. Perhaps I installed the emacs from different distributions, but I am not sure. Anyway, on the newer version it works fine. On the older version both don’t work - so I guess there is something else wrong there. I need to make both emacs’s on these machine the same! But I am not sure yet how…)

1 Like