bug-gnu-emacs
[Top][All Lists]
Advanced

[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






reply via email to

[Prev in Thread] Current Thread [Next in Thread]