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

[martin rudalics]

>> It would indeed be nice to fix that there in some way.
>
> There are not too many options that can be supported to make
> Emacs window management more manageable.  I see at least these:
>
> 1. If the user knows beforehand in which window to display some
>     particular buffer, then it's possible to customize display-buffer-alist.
>     For example, instead of displaying *Backtrace* in a random window
>     to make its placement more predictable:
>
>     (custom-set-variables
>      '(display-buffer-alist
>        '(("\\`\\*Backtrace.*" display-buffer-below-selected))))

That's the status quo, I suppose.

> 2. based on display-buffer-alist, implement some more declarative
>     definitions of window layouts, i.e. allow the user to describe
>     the used windows in which buffers should be displayed in them.

I'd need to see a proposal how that can be done.  In a way it's
orthogonal to how 'window-state-put' tries to reconstruct a window
configuration and it's no entirely trivial to do that.

> 3. in some cases there is an one-off need to point out explicitly
>     where to display the result of the next display-buffer command.
>     If this will require only short code addition then better to have
>     this feature in window.el.

I think that 'display-buffer-directionally' is supposed do that.  But
this should rather go to windmove.el because directional key bindings
are already in use there.

>> Good idea.  But IIUC we can't use 'hyper' in Emacs because it is not
>> supposed to be generally present and must be bound to a key first.  So
>> we'd need some other mechanism.
>
> This is the same mechanism as already used by windmove-default-keybindings.

'windmove-default-keybindings' binds only the 'shift' modifier which
is "standard" so to say.  Binding the 'hyper' modifier is not standard
to my knowledge.  We could bind any combination of 'shift', 'control'
and 'meta' though.

But I think that putting a function on
'window-configuration-change-hook' can be dangerous when a window
showing the buffer in question already exists and gets reused.  In
such case 'window-configuration-change-hook' is not run and the
changed value of 'display-buffer-overriding-action' will persist.  So
we probably need a 'display-buffer-functions' hook to remove it
reliably.  Basically, however, I think that using an overriding action
is justified here.

martin