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

From: martin rudalics <[email-masked]>
Date: Fri, 02 Nov 2018 09:44:49 +0100

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

Looks uncomfortable, unprofessional.  Do you think we can ever sell
that?

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

I understand now.

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

I had that in mind as a side-effect.  But we should really get rid of
this split-first-decide-what-to-put-there-afterwards approach first.

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

We could display a buffer that was previously shown in that window if
there is one.  But I think that such a buffer might be there just due
to a temporary excursion so I don't think it's a good idea.

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

'switch-to-buffer' obeys 'switch-to-buffer-preserve-window-point'
while 'pop-to-buffer-same-window' doesn't.  That's the main reason to
keep the present code (and one reason to replace 'switch-to-buffer'
with 'pop-to-buffer-same-window' in Lisp code).

There is also that special handling of dedicated windows but I doubt
it's ever needed in practice.  Dedicated windows are Stefan's
department and while I had to live with the ugliness of
'display-buffer-mark-dedicated' it also relieved me from caring about
specifying dedicatedness in buffer display elsewhere.

martin