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

[Juri Linkov]

>>> I forgot (or never learned) how to use it.  Can you please include an
>>> example so people can try it.
>>
>> An example is this:
> [...]
>
> Yes.  But when I now try your earlier example
>
> S-M-up M-x ffap RET RET
>
> with emacs -Q, after the S-M-up the *scratch* window is just split.
> What am I missing?

This is intended behavior - the window is split, so you can see the
window where a new buffer will be displayed after you invoke
the next command (e.g. 'ffap').

>> When display-buffer-directionally is called, it adds the hook
>> to post-command-hook, and when display-buffer-directionally finishes,
>> post-command-hook is called, and immediately removes itself from
>> post-command-hook.  This condition ensures that the hook is removed
>> only when post-command-hook is called after a next command finishes
>> (while the minibuffer is inactive).
>
> Can you give an example of a sequence of events how this should work
> in practice and which scenario it is supposed to avoid?  The term
> "next command" is not clear to me here.

An example of "next command" is 'ffap' in the earlier example.

> And wouldn't it be more intuitive to check the minibuffer depth
> instead?  That is, let the lambda succeed to do its job iff the
> current value of 'minibuffer-depth' equals the value of
> 'minibuffer-depth' at the time 'display-buffer-overriding-action' was
> set to the lambda.

Yes, this will allow using S-M-up from the active minibuffer.

>>>>            (window--display-buffer buffer ,win 'reuse alist)))))))
>>>
>>> 'reuse' holds only for the ?0 case.  When we split, the third argument
>>> should be 'window'.
>>
>> I noticed that when replaced with
>>
>> (window--display-buffer buffer ,win ',(if (eq dir ?0) 'reuse 'window) alist)
>>
>> then 'window means that killing the buffer will delete its window.
>
> What's bad about that?  What else do you want the window to show?  If
> the window got reused, it's natural to show the buffer it showed
> previously.  If the window was created anew, it's the most natural
> thing to delete it when its buffer gets killed.  If we want to change
> that, we can add an option.  But the way you do it, you completely
> mess up the semantics of the 'quit-restore' mechanism by faking its
> history.

Yes, killing the buffer without deleting its window will display
some random buffer in its place - this is bad.

>> Another observation is that switch-to-buffer is unaffected by this command.
>
> As long as it does not end up calling 'display-buffer', yes.

I'm not sure if switch-to-buffer should use pop-to-buffer-same-window,
probably not.