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

[martin rudalics]

>> With 'help-window-select' non-nil they should always select the help
>> window.
>
> This means that every package should provide own customization
> for the select/no-select choice for its windows, instead of
> a general solution like inhibit-window-select that I tried to do.

With help windows it was easy to do that because they never get
selected by default.

>> (1) The select/no-select choice always bound to one and the same
>> prefix key _regardless_ of the default behavior of the function (for
>> the buffer at hand), and
>
> This is implemented in a new version:
>
> (defun windmove-display-in-direction (dir &optional arg)
>    "Display the next buffer in the window at direction DIR.
> Create a new window if there is no window in that direction.
> Without a prefix arg, select the window with a displayed buffer.
> If prefix ARG is `C-u', reselect a previously selected window."

I'd invert these: The "-display-" infix implies that the buffer is
displayed and not popped to.  So with a prefix argumet I would select
the window in that direction and without it I'd leave the old window
selected.

>> Then (2) could be generalized via a global option to use/make a new
>> (child) frame in the indicated direction or whatever people want.
>
> But does windmove support frames in the first place?

No.

> Can you use e.g. S-left to select a frame on the left?
> Does window-in-direction currently return frames?

No, and it's a bit tricky to do that.  A window that is not on the
right of a frame has always exactly one window directly at its right
regardless of the position of its buffer's (window-)point.  The same
doesn't hold for a window that has a frame on the right.  If there are
two or more overlapping frames, we'd probably choose a visible one
with the highest z-order value.  If there is no frame directly on the
right of point, we'd have to choose the one geometrically nearest to
that position.

martin