[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: |
Sun, 02 Dec 2018 09:34:15 +0100 |
>> These ones stupefied me when I tried to study your patch yesterday.
>> When 'switch-to-buffer-obey-display-actions' is non-nil you do not
>> reset 'force-same-window' so you can get an error when this is t and
>> you're either in the minibuffer or the window is strongly dedicated.
>> Right?
>
> I don't understand how 'force-same-window' can be non-nil if there is
> a condition "unless switch-to-buffer-obey-display-actions" in the
> interactive spec. But if some code calls 'switch-to-buffer'
> non-interactively with non-nil 'force-same-window', should it
> signal an error when 'pop-to-buffer-same-window' displays the buffer
> in another window?
The non-interactive case is the one I had in mind. I think we mean to
say that FORCE-SAME-WINDOW has no impact in that case and
'switch-to-buffer' should not signal an error when the window is
dedicated or the minibuffer window but try to automatically display
the buffer in a window of its choice instead.
martin
- bug#32790: 27.0.50; point jumps unexpectedly after delete-window, Juri Linkov, 2018/12/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/12/02
- bug#32790: 27.0.50; point jumps unexpectedly after delete-window, martin rudalics, 2018/12/03
- bug#32790: 27.0.50; point jumps unexpectedly after delete-window, Juri Linkov, 2018/12/20
- bug#32790: 27.0.50; point jumps unexpectedly after delete-window, martin rudalics, 2018/12/21
- bug#32790: 27.0.50; point jumps unexpectedly after delete-window, Juri Linkov, 2018/12/22
- bug#32790: 27.0.50; point jumps unexpectedly after delete-window, martin rudalics, 2018/12/23