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

[martin rudalics]

>> Rather, the function on 'post-command-hook' would have to be more
>> intelligent - check whether the minibuffer-window is selected and
>> leave the overriding action untouched in that case.
>
> It's possible to implement it with post-command-hook, but the
> implementation will be more contorted - note that adding a hook
> to post-command-hook by a command will run it immediately
> at the end of this command and immediately remove the hook.

The mechanism must be safe in the first place and safety means here to
remove the mechanism before anything bad happens.

> Whereas window-state-change-functions elegantly checks
> if the window displays a new buffer.

But it fails when a window gets reused.  In general, any outcome of
'display-buffer' is possible, even 'allow-no-window'.  As soon as
'display-buffer' returns and no change of the window state happened we
are lost.

>> Moreover, using 'post-command-hook' would automatically fix any
>> problems when quitting an S-M-up action.  I see no way to catch
>> quitting via a state change of windows.
>
> What do you mean by quitting an S-M-up action?  minibuffer-exit?

Let's say anything C-g does.  I'm not sure whether we can catch that
always via 'minibuffer-exit-hook' though.  But it should not harm to
remove the overriding action in that case as well.

>> I forgot to ask: If that ffap pops up completions, they will appear
>> above the selected window.  Right?
>
> Right.  Since I agree this is not an expected behavior, here is a better
> version without this problem.  Instead of display-buffer-overriding-action,
> it uses display-buffer-alist because only display-buffer-alist
> supports a condition necessary to check for an active minibuffer.

As a rule, code must never fiddle with 'display-buffer-alist'.  If
anything gets wrong, the user is left with a broken customization.  If
'display-buffer-overriding-action' is not capable of handling this
scenario, then it's useless and we have to provide something better
anyway.

Now 'display-buffer-overriding-action' has the same deficiencies as
'pop-up-frames' and 'pop-up-windows'.  If you bind them around a
minibuffer interaction needed to find the buffer to display, you
affect that minibuffer interaction and any recursive 'display-buffer'
call that interaction emits too.

So what we need is a mechanism that (1) specifies a display action for
a buffer whose identity has not been specified yet at the time
'display-buffer' (or one of its callers) gets called and (2) does not
affect any calls of 'display-buffer' needed to get the identity of the
buffer needed by (1).  I think we agree on that.

So we want to delay the effect of 'display-buffer-overriding-action'
until it applies to the buffer the user had in mind when activating
the key combination.  Since we don't know the name of the buffer yet
(and in the worst case the name of the buffer the user wants to
display in a specific position is that of a buffer needed to find the
name), we need some sort of workaround.  I'm afraid we have to agree
on that as well.

I'm not sure whether checking 'minibuffer-depth' within the function
put on 'display-buffer-overriding-action' is sufficient.  That is,
have the overriding action take effect iff the depth is zero.  Please
check that first (I have no idea why you didn't try that before and
went for setting 'display-buffer-alist' instead).

If it doesn't help, we could equip 'display-buffer' itself with some
sort of recursion depth and allow the S-M- combination to apply only
when the level is zero.  We'd need some sort of escape to reset that
depth when a user aborts the buffer display action.  And it obviously
would disallow recursive application of the S-M- mechanism (like the
'minibuffer-depth' check approach).  So hopefully we find something
better.

But as soon as we have found a solution, we could provide prefixes to
handle all sorts of -same-window/-other-window/-other-frame and the
default display in a similar fashion.

martin