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

[Juri Linkov]

>> Actually it's a rare case when the same buffer is displayed
>> in two windows.  But I meant a more general case where all windows
>> display different buffers.  This is a more appropriate recipe
>> that avoids the same buffers:
>>
>> 0. emacs -Q
>>
>> 1. C-h e
>>
>> 2. C-x o
>>
>> 3. C-x 2
>>
>> 4. C-h i
>>
>> 5. C-x 0
>
> I meanwhile understand that in your case "C-h e" splits the original
> window horizontally, i.e. you get 2 windows side by side, not one
> above the other.  AFAICT, this was never explicitly mentioned in your
> bug report.

Sorry, I meant horizontally split windows.

> In any case, Martin explained the logic behind selecting another
> window in this case.  FWIW, I think the existing logic, which prefers
> the most recently selected window, is more sound than the one you
> propose, because screen positions can be more arbitrary/random than
> the MRU order.

This problem is quite rare since it resurfaces only when a frame has
more than 2 windows.  And every time the cursor jumps far away from
where it was before window deleting, it raises the question "Why?"

Now I understand that it jumps to the most recently selected window,
but this logic is not obvious.  Then why not to the most recently
displayed window?  Maybe we should have an option or at least hook
to define the preferred behavior.  Like there is the option
split-window-keep-point (applicable only to vertically split windows)
whose nil value provides more smooth effect (selects the window
depending on where point was before split, to avoid window scrolling).