[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: |
Thu, 15 Nov 2018 02:15:37 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (x86_64-pc-linux-gnu) |
>>> I'd invert these: The "-display-" infix implies that the buffer is
>>> displayed and not popped to.
>>
>> Then easier just to rename it to windmove-pop-in-direction
>> because most commands use pop-to-buffer, so this should be
>> the default.
>
> That would be much better.
The name 'windmove-display-in-direction' is more intuitive and still
correct because it displays. Select/no-select is a minor detail
that depends on the prefix arg and a variable that I propose to name
windmove-display-select.
>> 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'.
> 'switch-to-buffer' is different. Reconciling 'force-same-window' and
> 'switch-to-buffer-in-dedicated-window' looks rather painful to me.
>
>> I tried to temporarily set dedicated-p to an old window,
>> but switch-to-buffer removes its dedicatedness.
>
> What did you try exactly? Naively spoken, I suppose you would have
> bound the dedicated flag of the selected window to 't' to make
> sure it can't get used and 'switch-to-buffer-in-dedicated-window' to
> 'pop' to avoid a user error.
I tried to set switch-to-buffer-in-dedicated-window to t instead of 'pop'.
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.
Maybe simpler to rebind 'C-x b' from 'switch-to-buffer' to the command
'pop-to-buffer'? Is 'pop-to-buffer' equivalent to 'switch-to-buffer'
as a command with only difference in select/no-select behavior?
- 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 <=
- 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, 2018/11/15
- 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