GNU bug report logs - #49057
28.0.50; windmove-display-in-direction ignores windmove-display-no-select

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 49057 in the body.
You can then email your comments to 49057 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Ergus <spacibba <at> aol.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 28.0.50; windmove-display-in-direction ignores
 windmove-display-no-select
Date: Wed, 16 Jun 2021 08:42:48 +0200

Hi I just try to use the user option windmove-display-no-select and I
found that the new window is always selected and ignores
windmove-display-no-select.

To reproduce:

emacs -Q
M-: (setq windmove-display-no-select t)
M-x windmove-display-right
C-x b *scratch*

The new window will be selected independently of the value of
windmove-display-no-select.

Sometimes the new buffer is displayed in the current buffer ignoring
windmove-display-right (when *scratch* is already on the right for
example).

Message #8 received at 49057 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: 49057 <at> debbugs.gnu.org
Cc: Ergus <spacibba <at> aol.com>
Subject: Re: bug#49057: 28.0.50; windmove-display-in-direction ignores
 windmove-display-no-select
Date: Wed, 16 Jun 2021 10:59:50 +0300

> M-: (setq windmove-display-no-select t)
> M-x windmove-display-right
> C-x b *scratch*
>
> The new window will be selected independently of the value of
> windmove-display-no-select.
>
> Sometimes the new buffer is displayed in the current buffer ignoring
> windmove-display-right (when *scratch* is already on the right for
> example).

Please also do:

  M-: (setq switch-to-buffer-obey-display-actions t)

What we could do to improve this:

1. enable switch-to-buffer-obey-display-actions by default;

2. mention switch-to-buffer-obey-display-actions in more docstrings.

Currently the docstring of windmove-display-in-direction has this text:

  "When `switch-to-buffer-obey-display-actions' is non-nil,
  `switch-to-buffer' commands are also supported."

Maybe the same text should be copied to all commands that use
windmove-display-in-direction, i.e. to windmove-display-right,
etc.

Message #11 received at 49057 <at> debbugs.gnu.org (full text, mbox):

From: Ergus <spacibba <at> aol.com>
To: Juri Linkov <juri <at> linkov.net>
Cc: 49057 <at> debbugs.gnu.org
Subject: Re: bug#49057: 28.0.50; windmove-display-in-direction ignores
 windmove-display-no-select
Date: Wed, 16 Jun 2021 14:16:32 +0200

On Wed, Jun 16, 2021 at 10:59:50AM +0300, Juri Linkov wrote:
>> M-: (setq windmove-display-no-select t)
>> M-x windmove-display-right
>> C-x b *scratch*
>>
>> The new window will be selected independently of the value of
>> windmove-display-no-select.
>>
>> Sometimes the new buffer is displayed in the current buffer ignoring
>> windmove-display-right (when *scratch* is already on the right for
>> example).
>
>Please also do:
>
>  M-: (setq switch-to-buffer-obey-display-actions t)
>
>What we could do to improve this:
>
>1. enable switch-to-buffer-obey-display-actions by default;
>
>2. mention switch-to-buffer-obey-display-actions in more docstrings.
>
>Currently the docstring of windmove-display-in-direction has this text:
>
>  "When `switch-to-buffer-obey-display-actions' is non-nil,
>  `switch-to-buffer' commands are also supported."
>
>Maybe the same text should be copied to all commands that use
>windmove-display-in-direction, i.e. to windmove-display-right,
>etc.

Sorry, I forgot to mention that line but it is enabled but I already
have that in my config. Even with that it is not working fine.

Message #14 received at 49057 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Ergus <spacibba <at> aol.com>
Cc: 49057 <at> debbugs.gnu.org
Subject: Re: bug#49057: 28.0.50; windmove-display-in-direction ignores
 windmove-display-no-select
Date: Thu, 17 Jun 2021 02:08:57 +0300

> Sorry, I forgot to mention that line but it is enabled but I already
> have that in my config. Even with that it is not working fine.

Thanks for clarification, then we have a problem because
pop-to-buffer insists on always selecting the new window
that was displayed:

          ;; Make sure the window is selected (Bug#8615), (Bug#6954)
          (select-window window norecord))

Here is the workflow:

1. switch-to-buffer calls pop-to-buffer-same-window
2. pop-to-buffer-same-window calls pop-to-buffer
3. pop-to-buffer calls display-buffer
4. display-buffer calls display-buffer-override-next-command
   that calls post-function from windmove-display-in-direction
   that selects the old window

5. but later pop-to-buffer selects the new window,
   thus overriding the specified selection of the old window.

Message #17 received at 49057 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Juri Linkov <juri <at> linkov.net>, Ergus <spacibba <at> aol.com>
Cc: 49057 <at> debbugs.gnu.org
Subject: Re: bug#49057: 28.0.50; windmove-display-in-direction ignores
 windmove-display-no-select
Date: Thu, 17 Jun 2021 10:33:16 +0200

> 1. switch-to-buffer calls pop-to-buffer-same-window
> 2. pop-to-buffer-same-window calls pop-to-buffer
> 3. pop-to-buffer calls display-buffer
> 4. display-buffer calls display-buffer-override-next-command
>     that calls post-function from windmove-display-in-direction
>     that selects the old window
>
> 5. but later pop-to-buffer selects the new window,
>     thus overriding the specified selection of the old window.

Conceptually, `pop-to-buffer' has to

  Display buffer specified by BUFFER-OR-NAME and select its window.

so I cannot see anything wrong here.  Step 5 must be allowed to override
any selection made in step 4 and any expectation derived from having set
`windmove-display-no-select' to t is moot here.

[BTW, `windmove-display-in-direction' is not a command but its doc-string
talks about

  If ‘windmove-display-no-select’ is non-nil, this command doesn’t
  select the window with a displayed buffer, and the meaning of
  the prefix argument is reversed.

This should be fixed.]

Now we all know that `display-buffer' may or may not select the chosen
window.  We cannot disallow it when the window shall appear on a new
frame because most WMs will "select" the new frame.  Even trying to
disallow it in such case might be a bad idea because this instance of
`display-buffer' might have been triggered by a `pop-to-buffer' like
function and we will confuse the hell out of the WM - do not select the
new frame as `display-buffer' says, do select it as `pop-to-buffer' or
`switch-to-buffer' say ...

So maybe we should relax that basic statement of `display-buffer'

     This command makes BUFFER-OR-NAME appear in some window, without
     selecting the window or making the buffer current.

because it is wrong anyway.  Then we could add an additional action
alist entry, say 'select' with values like

- t (try to select)

- nil (avoid to select)

and maybe `never' or 'on-new-frame-only' to emphasize whether
`display-buffer' is allowed to select the window and make its buffer
current.  This has the advantage of freeing `display-buffer' from the
responsibility to decide whether it may select the chosen window.

Then we could also try to use frame parameters like 'no-focus-on-map'
and 'no-accept-focus' right away and users do not have to specify them
explicitly via `pop-up-frame-parameters'.

martin

Message #20 received at 49057 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 49057 <at> debbugs.gnu.org, Ergus <spacibba <at> aol.com>
Subject: Re: bug#49057: 28.0.50; windmove-display-in-direction ignores
 windmove-display-no-select
Date: Thu, 17 Jun 2021 22:54:48 +0300

tags 49057 fixed
thanks

> Conceptually, `pop-to-buffer' has to
>
>   Display buffer specified by BUFFER-OR-NAME and select its window.
>
> so I cannot see anything wrong here.  Step 5 must be allowed to override
> any selection made in step 4 and any expectation derived from having set
> `windmove-display-no-select' to t is moot here.

I completely agree.  All code that calls `pop-to-buffer' expects that
`pop-to-buffer' will select the displayed window, so code could continue
working on the selected window after its call.

So the only safe solution is to select the needed window in post-command-hook,
when the current command is already finished.  This is how this bug is fixed now.

> [BTW, `windmove-display-in-direction' is not a command but its doc-string
> talks about
>
>   If ‘windmove-display-no-select’ is non-nil, this command doesn’t
>   select the window with a displayed buffer, and the meaning of
>   the prefix argument is reversed.
>
> This should be fixed.]

Now fixed as well.

> Now we all know that `display-buffer' may or may not select the chosen
> window.  We cannot disallow it when the window shall appear on a new
> frame because most WMs will "select" the new frame.  Even trying to
> disallow it in such case might be a bad idea because this instance of
> `display-buffer' might have been triggered by a `pop-to-buffer' like
> function and we will confuse the hell out of the WM - do not select the
> new frame as `display-buffer' says, do select it as `pop-to-buffer' or
> `switch-to-buffer' say ...
>
> So maybe we should relax that basic statement of `display-buffer'
>
>      This command makes BUFFER-OR-NAME appear in some window, without
>      selecting the window or making the buffer current.
>
> because it is wrong anyway.  Then we could add an additional action
> alist entry, say 'select' with values like
>
> - t (try to select)
>
> - nil (avoid to select)
>
> and maybe `never' or 'on-new-frame-only' to emphasize whether
> `display-buffer' is allowed to select the window and make its buffer
> current.  This has the advantage of freeing `display-buffer' from the
> responsibility to decide whether it may select the chosen window.
>
> Then we could also try to use frame parameters like 'no-focus-on-map'
> and 'no-accept-focus' right away and users do not have to specify them
> explicitly via `pop-up-frame-parameters'.

But wouldn't this be too confusing for users, when users will call
`pop-to-buffer' with the new alist entry 'select', and it still will select
the unintended window as `pop-to-buffer' currently does?

Message #25 received at 49057 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Juri Linkov <juri <at> linkov.net>
Cc: 49057 <at> debbugs.gnu.org, Ergus <spacibba <at> aol.com>
Subject: Re: bug#49057: 28.0.50; windmove-display-in-direction ignores
 windmove-display-no-select
Date: Fri, 18 Jun 2021 09:33:40 +0200

> But wouldn't this be too confusing for users, when users will call
> `pop-to-buffer' with the new alist entry 'select', and it still will select
> the unintended window as `pop-to-buffer' currently does?

`pop-to-buffer' has to select the window chosen by `display-buffer'
regardless of whether `display-buffer' selected it or not.  Do we
violate this principle anywhere?  The basic difference I'd propose is to
have `pop-to-buffer' bind

 (display-buffer-overriding-action '(nil ((select . t))))

around the `display-buffer' call and so `display-buffer' will select the
chosen window regardless of any user customizations.

martin

Message #28 received at 49057 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 49057 <at> debbugs.gnu.org, Ergus <spacibba <at> aol.com>
Subject: Re: bug#49057: 28.0.50; windmove-display-in-direction ignores
 windmove-display-no-select
Date: Fri, 18 Jun 2021 22:10:02 +0300

>> But wouldn't this be too confusing for users, when users will call
>> `pop-to-buffer' with the new alist entry 'select', and it still will select
>> the unintended window as `pop-to-buffer' currently does?
>
> `pop-to-buffer' has to select the window chosen by `display-buffer'
> regardless of whether `display-buffer' selected it or not.  Do we
> violate this principle anywhere?  The basic difference I'd propose is to
> have `pop-to-buffer' bind
>
>  (display-buffer-overriding-action '(nil ((select . t))))
>
> around the `display-buffer' call and so `display-buffer' will select the
> chosen window regardless of any user customizations.

Then other commands should take care to not override
display-buffer-overriding-action.

Do you intend to rewrite commands that currently use
switch-to-buffer-other-window (such as Buffer-menu-other-window
and dired-find-file-other-window) to use `display-buffer'
with '(nil ((select . t)))?  Probably not because
switch-to-buffer-other-window already uses pop-to-buffer.

Then maybe you want to rewrite commands that currently use
`display-buffer' with ACTION=t (such as
Buffer-menu-switch-other-window and dired-display-file)
to use `display-buffer' with '(nil ((select . nil))) instead?

Message #33 received at 49057 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Juri Linkov <juri <at> linkov.net>
Cc: 49057 <at> debbugs.gnu.org, Ergus <spacibba <at> aol.com>
Subject: Re: bug#49057: 28.0.50; windmove-display-in-direction ignores
 windmove-display-no-select
Date: Sun, 20 Jun 2021 11:21:06 +0200

> Do you intend to rewrite commands that currently use
> switch-to-buffer-other-window (such as Buffer-menu-other-window
> and dired-find-file-other-window) to use `display-buffer'
> with '(nil ((select . t)))?  Probably not because
> switch-to-buffer-other-window already uses pop-to-buffer.
>
> Then maybe you want to rewrite commands that currently use
> `display-buffer' with ACTION=t (such as
> Buffer-menu-switch-other-window and dired-display-file)
> to use `display-buffer' with '(nil ((select . nil))) instead?

These do not use `pop-to-buffer' so I'd leave them alone.  Note that the
only value for 'select' I'd really care about is 'never' because it
means that `display-buffer' should try to refrain from focusing another
frame - provided the WM allows it.  But I doubt that people really care.

martin

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.