Bug: org-no-popups disregards display-buffer-fallback-action [9.4.6 (9.4.6-13-g4be129-elpaplus @ /home/jeeger/.emacs.d/elpa/org-plus-contrib-20210920/)]

Bug: org-no-popups disregards display-buffer-fallback-action [9.4.6 (9.4.6-13-g4be129-elpaplus @ /home/jeeger/.emacs.d/elpa/org-plus-contrib-20210920/)]

[Jan Seeger via General discussions about Org-mode.]

Hello!

I'm trying to make multi-frame emacsing nicer, and I encountered what I
consider a bug with the `org-no-popups` macro in `org-macs.el`.

`org-no-popups` tries to surpress the creation of new frames via setting
`pop-up-frames` and `display-buffer-alist` to nil temporarily. This does
not take `display-buffer-fallback-action` into account, which is the
preferred way of making Emacs pop up new frames (or not, as the case may
be). When the fallback variable is set, code run inside `org-no-popups`
still creates new popups, which causes functions such as
`org-insert-link` to fail, or at least act *very* confusingly.

The preferred way of overriding the behavior of `display-buffer` for
localized Emacs code seems to be the variable
`display-buffer-overriding-action`.

Changing the definition of `org-no-popups` to

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

correctly makes org pop up windows instead of frames.

Please contact me if you have any questions!

Best regards,
Jan Seeger

---

Emacs  : GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.30, cairo version 1.16.0)
Package: Org mode version 9.4.6 (9.4.6-13-g4be129-elpaplus @ /home/jeeger/.emacs.d/elpa/org-plus-contrib-20210920/)

Bug: org-no-popups disregards display-buffer-fallback-action [9.4.6 (9.4.6-13-g4be129-elpaplus @ /home/jeeger/.emacs.d/elpa/org-plus-contrib-20210920/)]

[Jan Seeger via General discussions about Org-mode.]

Hello!

I'm trying to make multi-frame emacsing nicer, and I encountered what I
consider a bug with the `org-no-popups` macro in `org-macs.el`.

`org-no-popups` tries to surpress the creation of new frames via setting
`pop-up-frames` and `display-buffer-alist` to nil temporarily. This does
not take `display-buffer-fallback-action` into account, which is the
preferred way of making Emacs pop up new frames (or not, as the case may
be). When the fallback variable is set, code run inside `org-no-popups`
still creates new popups, which causes functions such as
`org-insert-link` to fail, or at least act *very* confusingly.

The preferred way of overriding the behavior of `display-buffer` for
localized Emacs code seems to be the variable
`display-buffer-overriding-action`.

Changing the definition of `org-no-popups` to

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

correctly makes org pop up windows instead of frames.

Please contact me if you have any questions!

Best regards,
Jan Seeger

---

Emacs  : GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.30, cairo version 1.16.0)
Package: Org mode version 9.4.6 (9.4.6-13-g4be129-elpaplus @ /home/jeeger/.emacs.d/elpa/org-plus-contrib-20210920/)

Re: Bug: org-no-popups disregards display-buffer-fallback-action [9.4.6 (9.4.6-13-g4be129-elpaplus @ /home/jeeger/.emacs.d/elpa/org-plus-contrib-20210920/)]

[Ihor Radchenko]

Jan Seeger via "General discussions about Org-mode."
<emacs-orgmode@gnu.org> writes:

> Hello!
>
> I'm trying to make multi-frame emacsing nicer, and I encountered what I
> consider a bug with the `org-no-popups` macro in `org-macs.el`.

This problem has been fixed in Org 9.5. Feel free to update. See
https://orgmode.org/org.html#Installation for installation instructions.

Best,
Ihor

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

[Max Nikulin]

On 10/11/2021 14:50, Jan Seeger wrote:
>
> I'm trying to make multi-frame emacsing nicer, and I encountered what I
> consider a bug with the `org-no-popups` macro in `org-macs.el`.
>
> `org-no-popups` tries to surpress the creation of new frames via setting
> `pop-up-frames` and `display-buffer-alist` to nil temporarily. This does
> not take `display-buffer-fallback-action` into account, which is the
> preferred way of making Emacs pop up new frames (or not, as the case may
> be). When the fallback variable is set, code run inside `org-no-popups`
> still creates new popups, which causes functions such as
> `org-insert-link` to fail, or at least act *very* confusingly.
>
> The preferred way of overriding the behavior of `display-buffer` for
> localized Emacs code seems to be the variable
> `display-buffer-overriding-action`.
>
> Changing the definition of `org-no-popups` to
>
> ```
> (defmacro org-no-popups (&rest body)
>    "Suppress popup windows and evaluate BODY."
>    `(let ((display-buffer-overriding-action 
'(display-buffer-pop-up-window)))
>       ,@body))
> ```
>
> correctly makes org pop up windows instead of frames.

There were enough threads concerning displaying of buffers in Org, e.g.
https://list.orgmode.org/87mtnovv7f.fsf@alphapapa.net
https://list.orgmode.org/87zgrgke4b.fsf@ucl.ac.uk
Some users prefers multiple frames, others multiple windows in a 
full-screen frame. Could you, please, briefly describe what kind of 
behavior you are truing to achieve?

Overriding `display-buffer-alist' was certainly a mistake, users should 
be able to customize window creation. My impression is that 
`org-no-popups' is used in different scenarios that should have 
different default behavior.

Some Org buffers, in my opinion, should behave similarly to completion 
list. On the other hand `minibuffer-completion-help' does not use 
`display-buffer-overrining-action'. I do not like that this variable has 
higher priority than `display-buffer-alist'. Action argument of 
`display-buffer' is more appropriate since it keeps ability to customize 
placement of buffers with particular names through `display-buffer-alist'.

Thank you for suggesting `display-buffer-pop-up-window', current way of 
suppressing pop-up frames is unreliable. I am considering another 
option: '(nil (inhibit-switch-frame . t)) and I am unsure which variant 
is better. Actually I can not say that I really understand supposed ways 
to use `display-buffer' and related functions. My original expectation 
was that emacs should have a high level function for buffers similar to 
"*Completions*".

Re: Bug: org-no-popups disregards display-buffer-fallback-action [9.4.6 (9.4.6-13-g4be129-elpaplus @ /home/jeeger/.emacs.d/elpa/org-plus-contrib-20210920/)]

[dal-blazej]

I just inspected the git version.

Is the macro 'org-no-popups' setting _'pop-up-windows' to nil_ and is
only used by 'org-switch-to-buffer-other-window' that call
'switch-to-buffer-other-window' which in turn, 
set _'pop-up-windows' to t_ ?

Also 'pop-up-windows', 'pop-up-frame' are announced to be « provided
mainly for backward compatibility and should not be used in new code ».

As others I am currently advising a lot of org display functions to make
them obey to my 'display-buffer-alist'. I hope for a better cooperation
from org to window.el.

Best regards,
Dal.

Re: Bug: org-no-popups disregards display-buffer-fallback-action [9.4.6 (9.4.6-13-g4be129-elpaplus @ /home/jeeger/.emacs.d/elpa/org-plus-contrib-20210920/)]

[Ihor Radchenko]

dal-blazej@onenetbeyond.org writes:

> I just inspected the git version.
>
> Is the macro 'org-no-popups' setting _'pop-up-windows' to nil_ and is
> only used by 'org-switch-to-buffer-other-window' that call
> 'switch-to-buffer-other-window' which in turn, 
> set _'pop-up-windows' to t_ ?
>
> Also 'pop-up-windows', 'pop-up-frame' are announced to be « provided
> mainly for backward compatibility and should not be used in new code ».

You are right. org-no-popups was more widely used in the past. It is
probably time to obsolete it and eventually remove it.

AFAIU, org-no-popups is a legacy function introduced very long time ago.
Is it left there mostly to keep the working code working.

> As others I am currently advising a lot of org display functions to make
> them obey to my 'display-buffer-alist'. I hope for a better cooperation
> from org to window.el.

Can you elaborate? We are looking forward for ideas how to improve Org
in this area. More concrete suggestions are welcome.

Best,
Ihor

Re: Bug: org-no-popups disregards display-buffer-fallback-action [9.4.6 (9.4.6-13-g4be129-elpaplus @ /home/jeeger/.emacs.d/elpa/org-plus-contrib-20210920/)]

[Eric S Fraga]

On Sunday, 14 Nov 2021 at 14:08, Ihor Radchenko wrote:
> Can you elaborate? We are looking forward for ideas how to improve Org
> in this area. More concrete suggestions are welcome.

I posted about this some weeks ago.  It would be desirable to have org
manage window placement much less, if at all.  Emacs has sufficient
customizations possible for window management, display-buffer-alist
being the default variable to customize.  I am constantly fighting org
and find that it just does not allow me to configure window placement to
my satisfaction, especially on *ultra-wide* monitors.

My suggestion would be to remove all/most window management from org
itself and simply suggest possible settings for display-buffer-alist,
say.

To some degree, gnus suffers from the same control issues but Lars has,
as one would expect, provided an amazingly extensive fully customizable
window management configuration for gnus... I don't think org should go
to that extreme, however.

Thank you,
eric
-- 
: Eric S Fraga, with org release_9.5-228-g577b98 in Emacs 29.0.50
: Latest paper written in org: https://arxiv.org/abs/2106.05096

Re: Bug: org-no-popups disregards display-buffer-fallback-action [9.4.6 (9.4.6-13-g4be129-elpaplus @ /home/jeeger/.emacs.d/elpa/org-plus-contrib-20210920/)]

[Ihor Radchenko]

Eric S Fraga <e.fraga@ucl.ac.uk> writes:

> On Sunday, 14 Nov 2021 at 14:08, Ihor Radchenko wrote:
>> Can you elaborate? We are looking forward for ideas how to improve Org
>> in this area. More concrete suggestions are welcome.
>
> I posted about this some weeks ago.  It would be desirable to have org
> manage window placement much less, if at all.  Emacs has sufficient
> customizations possible for window management, display-buffer-alist
> being the default variable to customize.  I am constantly fighting org
> and find that it just does not allow me to configure window placement to
> my satisfaction, especially on *ultra-wide* monitors.

I thought that display-buffer-alist should be sufficient to control the
window placement in Org. Isn't it (on main)? 

I recall you posted a message about "window management for logging and
capturing notes", but you can easily change the capture window location
with display-buffer-alist.

> My suggestion would be to remove all/most window management from org
> itself and simply suggest possible settings for display-buffer-alist,
> say.

We still need to have reasonable defaults. They can always be
overwritten by display-buffer-alist.

Best,
Ihor

Re: Bug: org-no-popups disregards display-buffer-fallback-action [9.4.6 (9.4.6-13-g4be129-elpaplus @ /home/jeeger/.emacs.d/elpa/org-plus-contrib-20210920/)]

[Eric S Fraga]

On Sunday, 14 Nov 2021 at 20:40, Ihor Radchenko wrote:
> I thought that display-buffer-alist should be sufficient to control the
> window placement in Org. Isn't it (on main)?

I would have thought so but my experience has been that it isn't.
Capture buffers, in particular, did not seem to obey my settings.  I'll
play some more later this week and will report back because I possibly
didn't try hard enough...

> We still need to have reasonable defaults. They can always be
> overwritten by display-buffer-alist.

Yes (if the latter is true).  The defaults generally are fine (in my
experience) for normal sized monitors.

-- 
: Eric S Fraga, with org release_9.5-223-g876e81 in Emacs 29.0.50
: Latest paper written in org: https://arxiv.org/abs/2106.05096

Re: Bug: org-no-popups disregards display-buffer-fallback-action [9.4.6 (9.4.6-13-g4be129-elpaplus @ /home/jeeger/.emacs.d/elpa/org-plus-contrib-20210920/)]

[dal-blazej]

Ihor Radchenko <yantar92@gmail.com> writes:

>> As others I am currently advising a lot of org display functions to make
>> them obey to my 'display-buffer-alist'. I hope for a better cooperation
>> from org to window.el.
>
> Can you elaborate? We are looking forward for ideas how to improve Org
> in this area. More concrete suggestions are welcome.
>

The last time I looked into org-todo I seen that somewhere a call to
split-window was make, so wathever I was trying to configure with
display-buffer-alist would not conclude.

Then I translated that from Doom's Emacs.

#+begin_src emacs-lisp
;; Ensure todo, agenda, and other minor popups are delegated to the popup system.
;; needed for at least org-noter / org-insert-structure-template
(with-eval-after-load 'org
  (advice-add #'org-switch-to-buffer-other-window :override
              (defun +popup--org-pop-to-buffer-a (buf &optional norecord)
                "Use `pop-to-buffer' instead of `switch-to-buffer' to open buffer.'"
                (pop-to-buffer buf nil norecord)))

  (defun +popup--suppress-delete-other-windows-a (fn &rest args)
    (cl-letf (((symbol-function #'delete-other-windows) #'ignore)
              ((symbol-function #'delete-window) #'ignore))
      (apply fn args)))
  (dolist (fn '(org-add-log-note
                org-capture-place-template
                org-export--dispatch-ui
                org-agenda-get-restriction-and-command
                org-goto-location
                org-fast-tag-selection
                org-fast-todo-selection))
    (advice-add fn :around #'+popup--suppress-delete-other-windows-a))

  (advice-add #'org-fit-window-to-buffer :override #'fit-window-to-buffer))
#+end_src

You can see that it is not only the org-no-popup macro that is in
question but more generally the liberal usage of _split/switch/delete
windows_.

So if we want to make org cooperate with window.el we must ban theses
functions and instead delegate the window management with calls to
proper display functions.

Concretly if you look at org-fast-todo-selection you can see :

	(if expert
	    (set-buffer (get-buffer-create " *Org todo*"))
	  (delete-other-windows)
	  (set-window-buffer (split-window-vertically) (get-buffer-create " *Org todo*"))
	  (org-switch-to-buffer-other-window " *Org todo*"))

Now consider in place :

	(set-buffer (get-buffer-create " *Org todo*"))
        (unless expert
            (display-buffer " *Org todo*"
                            '((display-buffer-below-selected)
                              (window-height . fit-window-to-buffer))))
        

It will display this buffer below the currently selected window and fit
him.

Let's imagine the user wants in place to use :

(add-to-list 'display-buffer-alist
             '(" *Org todo*"
               (display-buffer-in-side-window)
               (side . top)))

Now the buffer display in a side window at top.

Re: Bug: org-no-popups disregards display-buffer-fallback-action [9.4.6 (9.4.6-13-g4be129-elpaplus @ /home/jeeger/.emacs.d/elpa/org-plus-contrib-20210920/)]

[Jan Seeger via General discussions about Org-mode.]

On 10.11.21 11:20, Ihor Radchenko wrote:
> Jan Seeger via "General discussions about Org-mode."
> <emacs-orgmode@gnu.org> writes:
>
>> Hello!
>>
>> I'm trying to make multi-frame emacsing nicer, and I encountered what I
>> consider a bug with the `org-no-popups` macro in `org-macs.el`.
> This problem has been fixed in Org 9.5. Feel free to update. See
> https://orgmode.org/org.html#Installation for installation instructions.
>
> Best,
> Ihor
>
Hello!

Thanks for your help, turns out the org-mode package changed its name from what I was using, which is why it didn't update automatically. An upgrade did indeed solve the problem.

Best regards,
Jan

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

[Jan Seeger via General discussions about Org-mode.]

On 13.11.21 14:15, Max Nikulin wrote:
> On 10/11/2021 14:50, Jan Seeger wrote:
>>
>> I'm trying to make multi-frame emacsing nicer, and I encountered what I
>> consider a bug with the `org-no-popups` macro in `org-macs.el`.
>>
>> `org-no-popups` tries to surpress the creation of new frames via setting
>> `pop-up-frames` and `display-buffer-alist` to nil temporarily. This does
>> not take `display-buffer-fallback-action` into account, which is the
>> preferred way of making Emacs pop up new frames (or not, as the case may
>> be). When the fallback variable is set, code run inside `org-no-popups`
>> still creates new popups, which causes functions such as
>> `org-insert-link` to fail, or at least act *very* confusingly.
>>
>> The preferred way of overriding the behavior of `display-buffer` for
>> localized Emacs code seems to be the variable
>> `display-buffer-overriding-action`.
>>
>> Changing the definition of `org-no-popups` to
>>
>> ```
>> (defmacro org-no-popups (&rest body)
>>    "Suppress popup windows and evaluate BODY."
>>    `(let ((display-buffer-overriding-action
>> '(display-buffer-pop-up-window)))
>>       ,@body))
>> ```
>>
>> correctly makes org pop up windows instead of frames.
>
> There were enough threads concerning displaying of buffers in Org, e.g.
> https://list.orgmode.org/87mtnovv7f.fsf@alphapapa.net
> https://list.orgmode.org/87zgrgke4b.fsf@ucl.ac.uk
> Some users prefers multiple frames, others multiple windows in a full-screen frame. Could you, please, briefly describe what kind of behavior you are truing to achieve?
>
> Overriding `display-buffer-alist' was certainly a mistake, users should be able to customize window creation. My impression is that `org-no-popups' is used in different scenarios that should have different default behavior.
>
> Some Org buffers, in my opinion, should behave similarly to completion list. On the other hand `minibuffer-completion-help' does not use `display-buffer-overrining-action'. I do not like that this variable has higher priority than `display-buffer-alist'. Action argument of `display-buffer' is more appropriate since it keeps ability to customize placement of buffers with particular names through `display-buffer-alist'.
>
> Thank you for suggesting `display-buffer-pop-up-window', current way of suppressing pop-up frames is unreliable. I am considering another option: '(nil (inhibit-switch-frame . t)) and I am unsure which variant is better. Actually I can not say that I really understand supposed ways to use `display-buffer' and related functions. My original expectation was that emacs should have a high level function for buffers similar to "*Completions*".
>

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

[Jan Seeger via General discussions about Org-mode.]

[-- Attachment #1: Type: text/plain, Size: 2434 bytes --]

Hello!

On 13.11.21 14:15, Max Nikulin wrote:
> Some users prefers multiple frames, others multiple windows in a full-screen frame. Could you, please, briefly describe what kind of behavior you are truing to achieve?

My thought is that I have a perfectly good window manager that allows me to manage Emacs frames. This removes the need for things to improve window switching (such as winner, which I used previously). Popping up frames to show multiple things at the same time integrates well with my WM, and doesn't force me to remap things like `C-x o`, which I find cumbersome to use. There are packages that make window switching easier, but I've already configured my window manager. 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)))

This allows me to pop up normal frames for regular buffers, and have special buffers pop up in windows to fix the "focus stealing" behavior mentioned above.

The central problem with popping up frames is focus stealing: Things such as undo-tree or embark don't deal well with having the focus stolen from the current buffer by a new frame, which is why I needed to configure `display-buffer-alist`.

> Some Org buffers, in my opinion, should behave similarly to completion list. On the other hand `minibuffer-completion-help' does not use `display-buffer-overrining-action'. I do not like that this variable has higher priority than `display-buffer-alist'. Action argument of `display-buffer' is more appropriate since it keeps ability to customize placement of buffers with particular names through `display-buffer-alist'.

I don't fully understand the `display-buffer-alist` definition, and copied mostly from the documentation examples.

I hope this helps.

Best regards,
Jan


PS: Sorry for the empty mail I sent previously.


[-- Attachment #2: Type: text/html, Size: 3318 bytes --]

Re: Bug: org-no-popups disregards display-buffer-fallback-action [9.4.6 (9.4.6-13-g4be129-elpaplus @ /home/jeeger/.emacs.d/elpa/org-plus-contrib-20210920/)]

[Eric S Fraga]

On Monday, 15 Nov 2021 at 00:03, dal-blazej@onenetbeyond.org wrote:
> So if we want to make org cooperate with window.el we must ban theses
> functions and instead delegate the window management with calls to
> proper display functions.

I agree completely.  One of my bug-bears is org-capture which I often
use during meetings to take notes or create TODO items.  Typically, the
org capture window covers my Teams buffer (I use exwm as my window
manager...) which is rather annoying.

I did play with display-buffer-alist but it seemed to not be able to
take control of some of org's windows.  Everything else I do in Emacs is
nicely managed through that alist.

-- 
: Eric S Fraga, with org release_9.5-223-g876e81 in Emacs 29.0.50
: Latest paper written in org: https://arxiv.org/abs/2106.05096

org-capture windows

[Max Nikulin]

On 15/11/2021 16:57, Eric S Fraga wrote:
> 
> I agree completely.  One of my bug-bears is org-capture which I often
> use during meetings to take notes or create TODO items.  Typically, the
> org capture window covers my Teams buffer (I use exwm as my window
> manager...) which is rather annoying.

It seems, your workflow is inconsistent with original org-capture idea. 
It was created at the time when screens were smaller and video meetings 
were not usual activity. It is only my guess however. Some event 
requiring capture interrupts current activity. It should be postponed 
till capture completion, so all other windows are removed to not 
distract you. As soon as capture finished you can resume the earlier 
activity, so previous window layout and positions in buffers are restored.

It is not bad approach per se but it is designed for frames with one or 
two buffers and incompatible with Emacs as window manager approach. I do 
not mind that such behavior should not be mandatory.

I have another example when current behavior is confusing. Browser and 
an Emacs frame are placed side by side. A group of related pages should 
be captured. Initial buffer and position is arbitrary. During capture of 
first page I jump to particular heading to cross-reference new note with 
some older topic. It is necessary to add a bit more to the same topic 
for a next web page but on capture completion buffer position is reset 
to previous value despite I was going to continue capture process.

Another problem is capture started through org-protocol without explicit 
template when template selection for previous capture was already 
active. Such kind of multi-tasking should not be a problem but it is 
since template key should be typed into minibuffer. I do not know what 
can be a proper solution. Maybe it can be a special mode with custom 
keymap for *Org Select* windows, so several such buffers may co-exist 
with no conflict due to minibuffer.

> I did play with display-buffer-alist but it seemed to not be able to
> take control of some of org's windows.  Everything else I do in Emacs is
> nicely managed through that alist.

A couple of months ago `display-buffer-alist' was overridden by 
`org-no-popups'. Currently you can put "\\*Org 
Select\\*\\|CAPTURE-.*\.org" buffers to e.g. side window. Unfortunately 
other windows are still wiped till capture completion.

Re: org-capture windows

[Eric S Fraga]

On Monday, 15 Nov 2021 at 23:54, Max Nikulin wrote:
> It seems, your workflow is inconsistent with original org-capture idea.
> It was created at the time when screens were smaller and video meetings
> were not usual activity. 

Indeed.  The beauty & power of Emacs is how it evolves to cater for
changing computing environments.  From tty to ulta-wide monitors!  But,
yes, I had no problems with how org-capture etc. worked until a) I
started using multiple large monitors and b) Emacs became my window
manager.

org needs to be less controlling basically (although reasonable defaults
are good, of course).

-- 
: Eric S Fraga, with org release_9.5-223-g876e81 in Emacs 29.0.50
: Latest paper written in org: https://arxiv.org/abs/2106.05096

Re: Bug: org-no-popups disregards display-buffer-fallback-action [9.4.6 (9.4.6-13-g4be129-elpaplus @ /home/jeeger/.emacs.d/elpa/org-plus-contrib-20210920/)]

[Daniel Kraus]

Eric S Fraga <e.fraga@ucl.ac.uk> writes:

> On Monday, 15 Nov 2021 at 00:03, dal-blazej@onenetbeyond.org wrote:
>> So if we want to make org cooperate with window.el we must ban theses
>> functions and instead delegate the window management with calls to
>> proper display functions.
>
> I agree completely.  One of my bug-bears is org-capture which I often
> use during meetings to take notes or create TODO items.  Typically, the
> org capture window covers my Teams buffer (I use exwm as my window
> manager...) which is rather annoying.
>
> I did play with display-buffer-alist but it seemed to not be able to
> take control of some of org's windows.  Everything else I do in Emacs is
> nicely managed through that alist.

Just want to mention that I would also really appreciate this.
I asked for it ~4 years ago on this list https://lists.gnu.org/archive/html/emacs-orgmode/2017-12/msg00241.html
and it also comes up from time to time in other places
like this Reddit thread https://www.reddit.com/r/emacs/comments/ic4u1m/stop_emacs_from_hiding_other_windows_when/

Thanks,
  Daniel

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

[Max Nikulin]

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.

Re: Bug: org-no-popups disregards display-buffer-fallback-action [9.4.6 (9.4.6-13-g4be129-elpaplus @ /home/jeeger/.emacs.d/elpa/org-plus-contrib-20210920/)]

[Ihor Radchenko]

Ihor Radchenko <yantar92@gmail.com> writes:

> dal-blazej@onenetbeyond.org writes:
>
>> I just inspected the git version.
>>
>> Is the macro 'org-no-popups' setting _'pop-up-windows' to nil_ and is
>> only used by 'org-switch-to-buffer-other-window' that call
>> 'switch-to-buffer-other-window' which in turn, 
>> set _'pop-up-windows' to t_ ?
>>
>> Also 'pop-up-windows', 'pop-up-frame' are announced to be « provided
>> mainly for backward compatibility and should not be used in new code ».
>
> You are right. org-no-popups was more widely used in the past. It is
> probably time to obsolete it and eventually remove it.
>
> AFAIU, org-no-popups is a legacy function introduced very long time ago.
> Is it left there mostly to keep the working code working.

I have reviewed all the uses of `org-switch-to-buffer-other-window' -
the only user of `org-no-popups' and it looks like the only reason we
don't use `switch-to-buffer-other-window' is let-binding `pop-up-frames'
to nil. Let-binding `pop-up-windows' is not effective because
`switch-to-buffer-other-window' binds (pop-up-windows t).

Considering that switching to popup frame is not Emacs default, it can
only happen when users deliberately changed display-buffer-alist in
their config. Disrespecting user settings is not something nice to do on
Org side.

I conclude that `org-no-popups' and `org-switch-to-buffer-other-window'
should not be used in Org mode.

Fixed, on main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=78dc58508

Other issues raised in this thread need more thought.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: Bug: org-no-popups disregards display-buffer-fallback-action [9.4.6 (9.4.6-13-g4be129-elpaplus @ /home/jeeger/.emacs.d/elpa/org-plus-contrib-20210920/)]

[Christopher M. Miles]

[-- Attachment #1: Type: text/plain, Size: 595 bytes --]


+1!

Ihor Radchenko <yantar92@posteo.net> writes:

> I conclude that `org-no-popups' and `org-switch-to-buffer-other-window'
> should not be used in Org mode.
>
> Fixed, on main.
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=78dc58508
>
> Other issues raised in this thread need more thought.


-- 

[ stardiviner ]
I try to make every word tell the meaning that I want to express without misunderstanding.

Blog: https://stardiviner.github.io/
IRC(libera.chat, freenode): stardiviner, Matrix: stardiviner
GPG: F09F650D7D674819892591401B5DF1C95AE89AC3

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: Bug: org-no-popups disregards display-buffer-fallback-action [9.4.6 (9.4.6-13-g4be129-elpaplus @ /home/jeeger/.emacs.d/elpa/org-plus-contrib-20210920/)]

[Ihor Radchenko]

Daniel Kraus <daniel@kraus.my> writes:

> Eric S Fraga <e.fraga@ucl.ac.uk> writes:
>
>> On Monday, 15 Nov 2021 at 00:03, dal-blazej@onenetbeyond.org wrote:
>>> So if we want to make org cooperate with window.el we must ban theses
>>> functions and instead delegate the window management with calls to
>>> proper display functions.
>>
>> I agree completely.  One of my bug-bears is org-capture which I often
>> use during meetings to take notes or create TODO items.  Typically, the
>> org capture window covers my Teams buffer (I use exwm as my window
>> manager...) which is rather annoying.
>>
>> I did play with display-buffer-alist but it seemed to not be able to
>> take control of some of org's windows.  Everything else I do in Emacs is
>> nicely managed through that alist.
>
> Just want to mention that I would also really appreciate this.
> I asked for it ~4 years ago on this list https://lists.gnu.org/archive/html/emacs-orgmode/2017-12/msg00241.html
> and it also comes up from time to time in other places
> like this Reddit thread https://www.reddit.com/r/emacs/comments/ic4u1m/stop_emacs_from_hiding_other_windows_when/

I believe that `display-buffer-alist' is fully obeyed now by Org mode (on
main branch). A few exceptions are when `org-agenda-window-setup' or/and
`org-src-window-setup' are customized to non-default value - then Org
does what the user asked for.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>