|
From: | Max Nikulin |
Subject: | Re: [PATCH] [BUG] Org 9.5: org-goto UI seems broken |
Date: | Mon, 18 Oct 2021 23:53:43 +0700 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 |
On 18/10/2021 16:25, Eric S Fraga wrote:
On Sunday, 17 Oct 2021 at 23:35, Max Nikulin wrote:So (setq display-buffer-base-action '((display-buffer-reuse-window display-buffer-pop-up-frame) (reusable-frames . 0))) should not be considered as shooting a foot.I am not sure I understand what you are or are not proposing but org should not be setting this variable. This variable is for the "user", not the package, to set.
I was trying to say that even with such *user* setup, behavior of Org should be reasonable. In particular, with draft patch I posted, *small* org-goto help buffer should not cause appearance of a new frame despite of `display-buffer-base-action' setting cited above, that is suitable for *regular* buffers. User still has opportunity to request arbitrary action for "*Org Help*" buffer through `display-buffer-alist'.
I actually think that org imposes too much of its own view on how buffers should be managed & displayed. I am constantly annoyed (and posted about this recently to the list with no response) that capture buffers pop up all over the place and it doesn't seem like I have any control at all.
I agree that behavior of `org-add-note' is extremely intrusive. On the other hand I have no idea concerning its preferred behavior by default.
I do not think that something like `org-src-window-setup' should be introduced for notes and captures. Ideally it should have reasonable behavior by default and should be adjustable through `display-buffer-alist'.
Currently I can not suggest a snippet for `display-buffer-alist' to exclude zoom or teams windows from candidates for `switch-to-buffer-other-window' (that is called from `org-capture').
[Prev in Thread] | Current Thread | [Next in Thread] |