[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#69993: Wrap window buffers while cycling
From: |
Juri Linkov |
Subject: |
bug#69993: Wrap window buffers while cycling |
Date: |
Thu, 28 Mar 2024 19:57:56 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/30.0.50 (x86_64-pc-linux-gnu) |
>>> What is the "fixed order"? When I use C-x b, that buffer becomes the
>>> one most recently shown in that window.
>>
>> The fixed order is similar to how tabs work in web browsers.
>> It would be unexpected when switching to a tab will always
>> move it to the end of the tab line. This is why it's unexpected
>> for C-x b to move tabs when tab-line-mode is used.
>
> But the lists of previous and next buffers have to reflect the order in
> which these buffers were shown in a window. You probably can't map them
> directly to tabs.
They are already mapped to tabs, and users happily used them for 5 years.
The only remaining problem the users complain about is that switching
buffers messes up the order. There is no problem in using a fixed order
because buffers will be still ordered by the order they were shown in a window.
Only need a way to switch between buffers already shown in a window.
For users of tab-line-mode there is no difference whether to use
'C-x C-left' or 'C-x b' to switch to the previous buffer.
>>> 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...
>>
>> I can't imagine why anyone would need wrapping when C-x C-left
>> will visit hundreds of buffers never shown in the window.
>
> Emacs "wrapped" in that case ever since (with at least two buffers).
The case of 'emacs -Q' has no practical significance.
>> So we need only two options: wrapping buffers shown in the window,
>> and to keep the fixed order of C-x b. So I will create a new request
>> for the fixed order of C-x b. And here is the final patch for wrapping:
>
> I still don't agree with it. IMHO we have to cater for two cases:
>
> (1) The classic behavior where switching may show a buffer never shown
> in the window before. I suppose you mean that
> 'switch-to-prev-buffer-wrap' does not affect it. If that's the
> case, please say so.
Indeed, 'switch-to-prev-buffer-wrap' does not affect it.
Switching to a buffer that was never shown in the window
should still reset the list of next-buffers to nil.
> (2) The new behavior where switching may only show buffers shown in that
> window before. For this you want to either wrap or not. So the
> option 'switch-to-prev-buffer-wrap' will affect (2) only. Right?
'switch-to-prev-buffer-wrap' will affect only 'C-x C-left' and 'C-x C-right'
cycling buffers shown in that window before.
- 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, 2024/03/27
- 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 <=
- 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