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

[Juri Linkov <juri@linkov.net>]

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?