[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#69993: Wrap window buffers while cycling
From: |
martin rudalics |
Subject: |
bug#69993: Wrap window buffers while cycling |
Date: |
Wed, 27 Mar 2024 09:48:38 +0100 |
User-agent: |
Mozilla Thunderbird |
>> I'm not sure I understand. IIRC 'window-next-buffers' always returns
>> nil unless you invoked 'switch-to-prev-buffer' before. It serves to
>> "navigate" a window's buffer list, in particular, to "undo" preceding
>> 'previous-buffer' calls when overshooting. 'switch-to-buffer' is not
>> part of such a scenario.
>
> A new option should always keep the fixed order, even when users use C-x b
> to visit a buffer that appeared in the window before.
What is the "fixed order"? When I use C-x b, that buffer becomes the
one most recently shown in that window.
> The problem is that there is no function that is called after
> set-window-buffer to reset the order of prev/next-buffers.
>
> set-window-buffer works that way that before changing the window buffer
> it calls record-window-buffer. But record-window-buffer has
> no information about new-buffer. So it can't reorder prev/next-buffers
> based on new-buffer that will be displayed in this window.
>
> Then later set-window-buffer sets window's buffer,
> but after that it doesn't call any function like
> record-window-buffer that could reorder prev/next-buffers.
>
> Then maybe possible to add such reordering after calling
> set-window-buffer? I mean such places as after calling
> set-window-buffer in window--display-buffer, and after calling
> set-window-buffer in switch-to-buffer.
Then give 'record-window-buffer' a second argument - the new buffer to
be shown. I'm a bit reluctant to work in this area - the introduction
of 'push-window-buffer-onto-prev' has obfuscated the code considerably
for no apparent use (at least one that I could understand).
> Ok, here is the current patch that supports the fixed order
> for 'C-x C-left' and 'C-x C-right' but still not for 'C-x b':
I see no problems with it. After C-x b *foo* I want to return to *foo*
via 'previous-buffer' after switching to *bar* via a second C-x b. What
would you want to see instead? Maybe I still misunderstand you.
I think 'switch-to-prev-buffer-wrap' already confuses things. Wrapping,
for me, means to wrap around like when navigating on a ring of buffers.
Whether this should include buffers never shown in the window before is
a different issue IMO. And whether C-x b should change the order is yet
another issue. So maybe we need three options instead of one...
martin
- bug#69993: Wrap window buffers while cycling, Juri Linkov, 2024/03/25
- bug#69993: Wrap window buffers while cycling, martin rudalics, 2024/03/25
- bug#69993: Wrap window buffers while cycling, Juri Linkov, 2024/03/25
- bug#69993: Wrap window buffers while cycling, martin rudalics, 2024/03/26
- bug#69993: Wrap window buffers while cycling, Juri Linkov, 2024/03/27
- bug#69993: Wrap window buffers while cycling,
martin rudalics <=
- bug#69993: Wrap window buffers while cycling, Juri Linkov, 2024/03/28
- bug#69993: Wrap window buffers while cycling, martin rudalics, 2024/03/28
- bug#69993: Wrap window buffers while cycling, Juri Linkov, 2024/03/28
- bug#69993: Wrap window buffers while cycling, martin rudalics, 2024/03/29
- bug#69993: Wrap window buffers while cycling, Juri Linkov, 2024/03/29
- bug#69993: Wrap window buffers while cycling, martin rudalics, 2024/03/30
- bug#69993: Wrap window buffers while cycling, Juri Linkov, 2024/03/30
- bug#69993: Wrap window buffers while cycling, martin rudalics, 2024/03/31