Re: Bug: org-no-popups disregards display-buffer-fallback-action 9.4.6

[Max Nikulin <manikulin@gmail.com>]

On 15/11/2021 14:49, Jan Seeger wrote:
> On 13.11.21 14:15, Max Nikulin wrote:
> 
> My thought is that I have a perfectly good window manager that allows me 
> to manage Emacs frames.
> ... Thus, I prefer to have my 
> window manager manage Emacs frames, instead of adding yet another way to 
> switch between multiple things being displayed at the same time, which I 
> would have to do using Emacs windows.
> 
> My current configuration is as follows:
> 
> (setq display-buffer-base-action '((display-buffer-reuse-window display-buffer-pop-up-frame)
>                                     (reusable-frames . 0)))
> (setq display-buffer-alist
>        `(("\\*Packages\\*" display-buffer-pop-up-frame)
>          ("\\*stdin.*\\*" display-buffer-same-window)
>          ("\\*Help\\*" display-buffer-pop-up-frame)
>          ("\\*.*\\*" display-buffer-pop-up-window)))

Thank you for sharing this. I have tried such setup. Behavior of Org 
windows is terrible. "Standard" Emacs windows may be a bit strange 
sometimes, but it is not really annoying.

If there is a *Help* buffer on the screen, another one is created if 
help is called from some other buffer. Content of help frames is 
synchronized. I suppose, second help frame on the same screen may be 
avoided by adjusting configuration. (Side note: sometimes I do not mind 
to have several help buffers showing different content, so I do not like 
current limitation of help facilities.)

Frame may be split into halves by e.g. debugger window, C-h e, etc. It 
does not matter whether it is full-screen or half-screen frame (OK, in 
first case it split by vertical line, in second one by horizontal). Next 
similar buffer is opened in new frame. I would expect that either always 
new frame is created or decision depends on window size, not on number 
of windows (1 or 2) in the frame.

I have tried your suggestion

> (defmacro org-no-popups (&rest body)
>   "Suppress popup windows and evaluate BODY."
>   `(let ((display-buffer-overriding-action '(display-buffer-pop-up-window)))
>      ,@body))

It requires more work. C-c C-j org-goto is obviously broken with your 
config due to recent changes. It fixes only first step of org-capture 
(template selection) is fixed, window with buffer for capture is created 
in the current frame, but new clone of frame is created.

I am still in doubts whether `display-buffer-overriding-action' or 
ACTION argument of `display-buffer' should be used.

Actually I think that even org-capture should have two different 
options: with new frame or withing existing frame. Maybe I will explain 
it in detail in other part of this thread is response to Eric's message.