bug#32790: 27.0.50; point jumps unexpectedly after delete-window

[Juri Linkov]

>>> I'd invert these: The "-display-" infix implies that the buffer is
>>> displayed and not popped to.
>>
>> Then easier just to rename it to windmove-pop-in-direction
>> because most commands use pop-to-buffer, so this should be
>> the default.
>
> That would be much better.

The name 'windmove-display-in-direction' is more intuitive and still
correct because it displays.  Select/no-select is a minor detail
that depends on the prefix arg and a variable that I propose to name
windmove-display-select.

>> But currently I'm more concerned about inability to use switch-to-buffer,
>> i.e. trying to display a buffer in another window with ‘S-M-down C-x b RET’
>> doesn't work.
>
> You mean wherever we can't use 'pop-to-buffer-same-window' instead?

Yes, and 'switch-to-buffer' should not use 'pop-to-buffer-same-window'.

> 'switch-to-buffer' is different.  Reconciling 'force-same-window' and
> 'switch-to-buffer-in-dedicated-window' looks rather painful to me.
>
>> I tried to temporarily set dedicated-p to an old window,
>> but switch-to-buffer removes its dedicatedness.
>
> What did you try exactly?  Naively spoken, I suppose you would have
> bound the dedicated flag of the selected window to 't' to make
> sure it can't get used and 'switch-to-buffer-in-dedicated-window' to
> 'pop' to avoid a user error.

I tried to set switch-to-buffer-in-dedicated-window to t instead of 'pop'.
But I see now it's not worth the trouble to handle dedicatedness in
'windmove-display-in-direction' because it's not a general solution.

Maybe simpler to rebind 'C-x b' from 'switch-to-buffer' to the command
'pop-to-buffer'?  Is 'pop-to-buffer' equivalent to 'switch-to-buffer'
as a command with only difference in select/no-select behavior?