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

[Juri Linkov]

> Shouldn't (selected-window) be actually (minibuffer-selected-window)
> in these cases anyway?  Otherwise, we probably should invent two
> scenarios where either of the above would be preferable so we can make
> a decision.

Probably you meant (or (minibuffer-selected-window) (selected-window))

>> +  "Display the next buffer in the window at direction DIR.
>> +Create a new window if there is no window in that direction.
>> +If prefix ARG is `C-u' or `M--', restore the previously selected window.
>> +With no prefix ARG, or with prefix ARG equal to zero, a displayed window is
>> +relative to the position of point in the selected window; otherwise it is
>> +relative to the first edge (for positive ARG or `C-u') or the last edge
>> +(for negative ARG or `M--') of the selected window."
>
> What does "otherwise" stand for here?  (I'm afraid your prefix
> arguments are slowly getting over my head.)

This summarizes the prefix keys where 'default' is the default
window selection behavior, and 'window-noselect' restores a previously
selected window:

                                    default     window-noselect
relative to the position of point   no prefix   M-0
relative to the first edge          M-1         C-u
relative to the last edge           M-- 1       M--

But maybe also another choice 'window-select' should be added to
force window selection?  I mean that some commands don't select
the displayed window by default, e.g. help commands like
'C-h e', 'C-h f', 'C-h v', 'C-h k' after their invocation
don't select the window with the *Help* buffer.

Or maybe a prefix key should invert the default behavior,
e.g. 'S-M-right C-x v =' by default selects the displayed window,
so ‘C-u S-M-right C-x v =’ will not select the window.
'S-M-right C-h e' by default doesn't select the window,
so ‘C-u S-M-right C-h e’ will select the window.