[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#32790: 27.0.50; point jumps unexpectedly after delete-window
From: |
martin rudalics |
Subject: |
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
- bug#32790: 27.0.50; point jumps unexpectedly after delete-window, martin rudalics, 2018/11/01
- bug#32790: 27.0.50; point jumps unexpectedly after delete-window, Juri Linkov, 2018/11/01
- bug#32790: 27.0.50; point jumps unexpectedly after delete-window,
martin rudalics <=
- bug#32790: 27.0.50; point jumps unexpectedly after delete-window, Juri Linkov, 2018/11/04
- bug#32790: 27.0.50; point jumps unexpectedly after delete-window, martin rudalics, 2018/11/05
- bug#32790: 27.0.50; point jumps unexpectedly after delete-window, Juri Linkov, 2018/11/05
- bug#32790: 27.0.50; point jumps unexpectedly after delete-window, martin rudalics, 2018/11/06
- bug#32790: 27.0.50; point jumps unexpectedly after delete-window, Juri Linkov, 2018/11/06
- bug#32790: 27.0.50; point jumps unexpectedly after delete-window, martin rudalics, 2018/11/07
- bug#32790: 27.0.50; point jumps unexpectedly after delete-window, Juri Linkov, 2018/11/07