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

[Juri Linkov <juri@linkov.net>]

>> +;;; Directional window deletion
>> +
>> +(defun windmove-delete-in-direction (dir &optional arg)
>> +  "Delete the window at direction DIR.
>> +If prefix ARG is `C-u', delete the selected window and
>> +select the window at direction DIR."
>> +  (let ((other-window (window-in-direction dir nil nil arg
>> +                                           windmove-wrap-around t)))
>
> So 'windmove-wrap-around' non-nil means that the other window could be
> the selected one and we try to delete ourselves.  Right?

Fortunately, 'windmove-wrap-around' doesn't wrap to the same window
when there is only one window in that direction.

>> +          ((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)

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.