bug#49057: 28.0.50; windmove-display-in-direction ignores windmove-display-no-select

bug#49057: 28.0.50; windmove-display-in-direction ignores windmove-display-no-select

[Ergus via Bug reports for GNU Emacs, the Swiss army knife of text editors]

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).

bug#49057: 28.0.50; windmove-display-in-direction ignores windmove-display-no-select

[Juri Linkov]

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

bug#49057: 28.0.50; windmove-display-in-direction ignores windmove-display-no-select

[Ergus via Bug reports for GNU Emacs, the Swiss army knife of text editors]

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.

bug#49057: 28.0.50; windmove-display-in-direction ignores windmove-display-no-select

[Juri Linkov]

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

bug#49057: 28.0.50; windmove-display-in-direction ignores windmove-display-no-select

[martin rudalics]

 > 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

bug#49057: 28.0.50; windmove-display-in-direction ignores windmove-display-no-select

[Juri Linkov]

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?

bug#49057: 28.0.50; windmove-display-in-direction ignores windmove-display-no-select

[martin rudalics]

 > 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

bug#49057: 28.0.50; windmove-display-in-direction ignores windmove-display-no-select

[Juri Linkov]

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

bug#49057: 28.0.50; windmove-display-in-direction ignores windmove-display-no-select

[martin rudalics]

 > 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