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

[Juri Linkov]

>> The problem is that the cursor jumps to the distant part of the frame
>> too far from the current focus.  It takes additional efforts to bring
>> it back where the input focus was.  It's more about visual perception.
>
> But then we have to care about the position of each window's point as
> well.  Consider the case of a vertical combination of three windows
> with all windows' points at their top.  Deleting the middle window
> should then probably select the lower window.  With all points at
> their windows' bottoms we probably should select the upper window.

A good analogy is what other tabbed UI like web browsers do
on tab closing.  For example, Firefox add-on Tab Mix Plus

http://www.tabmixplus.org/support/viewtopic.php?t=3

provides an option with such values

  When closing the current tab, focus (select one):

  - First tab
  - Left tab
  - Right tab
  - Last tab
  - Last selected tab
  - Opener/Right tab (the tab containing the link that opened this tab or the 
tab to the right)
  - Last opened tab

The current Emacs behavior that selects the most recently used window
corresponds to "Last selected tab".  "Last opened tab" could correspond
to the most recently displayed window.  And "Left tab" could mean to
select the left sibling.

>> It seems the logic of deciding to which sibling to give the space back
>> is fine now.  The need is to select the same window that got the space
>> after C-x 0.
>
> We can add an option for that.  How should we call it?

The name depends on possible values.

If the values are 'sibling, 'mru, and possibly a user-defined function,
then a suitable name could be say, after-delete-window-select, or if this
name looks like a hook name, then simply delete-window-select.