GNU bug report logs - #32790
27.0.50; point jumps unexpectedly after delete-window

Previous Next

Full log

Message #158 received at 32790 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Juri Linkov <juri <at> linkov.net>
Cc: 32790 <at> debbugs.gnu.org
Subject: Re: bug#32790: 27.0.50; point jumps unexpectedly after delete-window
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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.