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

[Juri Linkov <juri@linkov.net>]

>>>> +          ((and (window-minibuffer-p other-window)
>>>> +                (not (minibuffer-window-active-p other-window)))
>>>> +           (user-error "Minibuffer is inactive"))
>>>
>>> Should we try to delete the active minibuffer window?
>>
>> Interesting question.  Do you think it's worth the trouble
>> to implement special handling of the minibuffer:
>>
>> 1. when a window in the below direction is requested to be deleted
>>     from the bottom window, and the minibuffer is active,
>>     then call (abort-recursive-edit)
>
> This looks counter-intuitive unless we are also able to delete the
> minibuffer window.

But the minibuffer window can't be deleted:

0. emacs -Q
1. M-:
2. C-x o
3. Type and eval in *scratch*: (delete-window (window-in-direction 'below))

This error is signaled: "Attempt to delete minibuffer or sole ordinary window"

>> 2. when the selected bottom window is requested to be deleted
>>     and selection is requested to be moved in the below direction,
>>     then the minibuffer's window should be selected.
>
> If it's active, presumably.  I'm not sure, but I wouldn't do that in a
> first version.  BTW, if you delete the window on the right frame
> border and want selection to move to the right, does it wrap around to
> the window on the left?

Yes, it respects windmove-wrap-around.