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 (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 (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

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 (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>