[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#32790: 27.0.50; point jumps unexpectedly after delete-window
From: |
Juri Linkov |
Subject: |
bug#32790: 27.0.50; point jumps unexpectedly after delete-window |
Date: |
Fri, 16 Nov 2018 00:59:59 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (x86_64-pc-linux-gnu) |
>>>> But currently I'm more concerned about inability to use switch-to-buffer,
>>>> i.e. trying to display a buffer in another window with ‘S-M-down C-x b RET’
>>>> doesn't work.
>>>
>>> You mean wherever we can't use 'pop-to-buffer-same-window' instead?
>>
>> Yes, and 'switch-to-buffer' should not use 'pop-to-buffer-same-window'.
>
> You mean uses of 'switch-to-buffer' in code that we cannot (or are too
> lazy to) replace with 'pop-to-buffer-same-window'. Right? Because
> ideally code should not use 'switch-to-buffer' - we had quite a number
> of reports that the point restoring mechanism conflicted with the
> purpose to show a preselected buffer position in the selected window.
Whereas I meant mostly switch-to-buffer as a command bound to 'C-x b',
non-interactive calls of 'switch-to-buffer' have the same problem, and
maybe some of them could be replaced with 'pop-to-buffer-same-window'
without side effects. One example is 'C-h C-n' (view-emacs-news) that
uses switch-to-buffer, and can't be forced into another window.
I solved this general problem for myself with such advice:
(advice-add 'switch-to-buffer :around
(lambda (orig-fun &rest args)
(let ((buffer (apply orig-fun args))
(window (selected-window)))
(switch-to-prev-buffer window)
(pop-to-buffer-same-window buffer))))
Then 'S-M-right C-h C-n' shows it in the right window.
Do you think it's possible to add a corresponding customizable option
that would provide the same behavior?
>> I tried to set switch-to-buffer-in-dedicated-window to t instead of 'pop'.
>
> I miss you here: Above you say that you want to display the buffer in
> another window. But setting 'switch-to-buffer-in-dedicated-window' to
> t is useful only when you insisit on using the selected window.
I tried t mistakenly. I intended to try 'pop' that works ok.
>> But I see now it's not worth the trouble to handle dedicatedness in
>> 'windmove-display-in-direction' because it's not a general solution.
>
> Windows have been often made dedicated so they get auto-deleted as
> soon as their buffer gets buried or killed. This use-case should now
> be handled by the 'quit-restore' parameter. I have no idea whether
> windows are made dedicated for any other reason. Do you?
Another reason would be to force pop-up from switch-buffer, but
it's not the right thing to do.
- bug#32790: 27.0.50; point jumps unexpectedly after delete-window, (continued)
- bug#32790: 27.0.50; point jumps unexpectedly after delete-window, Juri Linkov, 2018/11/08
- bug#32790: 27.0.50; point jumps unexpectedly after delete-window, martin rudalics, 2018/11/09
- bug#32790: 27.0.50; point jumps unexpectedly after delete-window, Juri Linkov, 2018/11/10
- bug#32790: 27.0.50; point jumps unexpectedly after delete-window, martin rudalics, 2018/11/11
- bug#32790: 27.0.50; point jumps unexpectedly after delete-window, Juri Linkov, 2018/11/12
- bug#32790: 27.0.50; point jumps unexpectedly after delete-window, martin rudalics, 2018/11/13
- bug#32790: 27.0.50; point jumps unexpectedly after delete-window, Juri Linkov, 2018/11/13
- bug#32790: 27.0.50; point jumps unexpectedly after delete-window, martin rudalics, 2018/11/14
- bug#32790: 27.0.50; point jumps unexpectedly after delete-window, Juri Linkov, 2018/11/14
- bug#32790: 27.0.50; point jumps unexpectedly after delete-window, martin rudalics, 2018/11/15
- bug#32790: 27.0.50; point jumps unexpectedly after delete-window,
Juri Linkov <=
- bug#32790: 27.0.50; point jumps unexpectedly after delete-window, martin rudalics, 2018/11/16
- bug#32790: 27.0.50; point jumps unexpectedly after delete-window, Juri Linkov, 2018/11/17
- bug#32790: 27.0.50; point jumps unexpectedly after delete-window, martin rudalics, 2018/11/18
- bug#32790: 27.0.50; point jumps unexpectedly after delete-window, Juri Linkov, 2018/11/18
- bug#32790: 27.0.50; point jumps unexpectedly after delete-window, martin rudalics, 2018/11/19
- bug#32790: 27.0.50; point jumps unexpectedly after delete-window, Juri Linkov, 2018/11/19
- bug#32790: 27.0.50; point jumps unexpectedly after delete-window, martin rudalics, 2018/11/20
- bug#32790: 27.0.50; point jumps unexpectedly after delete-window, Juri Linkov, 2018/11/20
- bug#32790: 27.0.50; point jumps unexpectedly after delete-window, martin rudalics, 2018/11/21
- bug#32790: 27.0.50; point jumps unexpectedly after delete-window, Juri Linkov, 2018/11/21