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

[martin rudalics <rudalics@gmx.at>]

 > 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