org-roam-window-mode for easy roaming

[sdorof1]

Brief Abstract

org-roam-window-mode to organize the windows for easy roaming.

Long Description

1. Each link (file, or ID) should be open in a new window on the right.

2. All windows to the left and to the right of the current one, except for the previous one, from which we roamed to this window, must shrink their width. (Similar to the golden-ratio mode, but there should be present the two full-width windows in the center, not one.)

3. When roaming by link, all previous windows to the right of the new window should be closed.

4. The backlinks window should not be resized while creating / deleting / resizing other windows.

At the moment, opening link in new window on the right can be achieved by manually splitting the current window. But this works only for links to files, and does not work for links by ID, that opens in the current window.

Please check the following:

• No similar feature requests

[Wetlize]

I really like this, but I'm not sure how feasible is this in Emacs, since, say, unlike something as Obsidian's Andy Matuschak mode, Emacs doesn't provide infinite space to split windows over and over, so you will eventually reach Window too small for splitting error.

I think it could be possible to workaround the limitation at the UX level. For example, once a certain threshold is reached, all current windows could be paged in a data structure, then the frame would automatically clear up all the windows, except the last 2 visited, keeping them visible. Then each such page could be optionally exposed to the user as a node in a graph, similarly to how undo-tree renders it:

The image is taken from #531, which is connected to this issue.

Stepping on each node would swap active windows to the one stored in the page. If the user would change windows it would create a new branch and so on.

This might be overcomplicated and need verification with a prototype, but for now, I'm just throwing some ideas.

[jethrokuan]

This sort of window management is definitely possible, but it's not in the scope of Org-roam. In fact, you don't need any information from Org-roam at all: this can work with regular links, and each window just needs to keep track of the buffer/window that spawned it.

I don't have time to work on this anytime soon, but I'll leave it here for now for discussion and see if there are any takers.

[sdorof1]

Personally I'm now attempt to start active using org-roam, and I see a huge potential of using it, and it gives me very good results already. But very big problem is the windows management while roaming: its really confusing to boring with split/move/resize/close windows while flowing through notes.

I can some put up with this problem if all links are a file-links, because then my workflow is to split current buffer, and the link will be open in a new buffer on the right, or, if a such buffer already is open, the corresponding window will be activated. But the id-links (it is preffered link type for me for some reasons, and I see, it is also preffered link type for org-roam) currently are opens in the current window, no matter is there a window on the right, or is the some window where id-linked buffer already shown. It completelly frustrates the flow. So, although I myself presonally very interested in the proposed enhancement, but I also think, this enhancement will be a very inviting feature of org-roam for everyone.

As a minimal enhancement it should be give the id-links the same behaviour as for file-links: open them in the window on the right, and going to the already shown windows with referred buffers.

[publicimageltd]

@sdorof1 I currently use embark to open the links. Embark allows you to create context menus for the thing at point, e.g. for org mode links. See https://github.com/oantolin/embark/.

This allows me to add a function to open the link in the side window. Here's the config:

(defun jv-get-create-side-window ()
  "Return side window, or create one."
  (when (one-window-p)
    (split-window-horizontally))
  (or (window-in-direction 'right)
      (window-in-direction 'left)
      (selected-window)))
  ;; teach embark to visit org links:
  (defun embark-target-org-link-at-point ()
    "Teach embark to reconize org links at point."
    (when (org-in-regexp org-link-any-re)
      (cons 'org-link (match-string-no-properties 0))))
  (defun jv-org-open-link-string-in-side-window (s)
    (select-window (jv-get-create-side-window))
    (org-link-open-from-string s))
  (embark-define-keymap embark-org-link-map
    "Keymap for org links."
    ("RET" org-open-at-point-global)
    ("o" jv-org-open-link-string-in-side-window))
  (advice-add 'org-open-at-point-global :before #'push-mark)
  (add-to-list 'embark-target-finders
               #'embark-target-org-link-at-point)
  (add-to-list 'embark-keymap-alist
               '(org-link . embark-org-link-map))

With this snippet, you can:

• Open a link the regular way (within the window) by calling embark-act and pressing enter. (I recommend to bind embark-act to a key).
• Open a link in an other window by calling embark-actand pressing o. It either uses an existing window to the right, or creates one.

Currently, point is kept in the buffer where the link originates from, but it wouldn't be complicated to change it.