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

[martin rudalics <rudalics@gmx.at>]

 >> 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?

 > 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.

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.

 >>> 		(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.

 > Another observation is that switch-to-buffer is unaffected by this command.

As long as it does not end up calling 'display-buffer', yes.

martin