GNU bug report logs - #13167
24.3.50; C-x right C-x left interferes with buffer order

Previous Next

Full log

Message #41 received at 13167 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Juri Linkov <juri <at> jurta.org>
Cc: 13167 <at> debbugs.gnu.org
Subject: Re: bug#13167: 24.3.50; C-x right C-x left interferes with buffer
	order
Date: Sat, 22 Dec 2012 16:41:56 +0100

> As I see, the list of previous buffers is not empty,
> but I don't know why it doesn't restore the *scratch* buffer.

Yes, but all buffers on the list of previous buffers including *scratch*
are on the list of next buffers too.  So it takes a buffer from some
global list :-(

If we want to patch this in your sense, whenever all previous buffers are
next we have to take the latest buffer on next instead IIUC.

> As a general question, do you know a reason why structure and functionality
> of window-local `prev-buffers' and `next-buffers' should differ from
> frame-local frame parameters `buffer-list' and `buried-buffer-list'?
>
> I have a feeling that adding the handling of window-local counterparts
> `prev-buffers' and `next-buffers' to the same places in code that currently
> handle frame-local buffer lists `buffer-list' and `buried-buffer-list'
> could help to fix all these window-related buffer-order inconsistencies.

The idea of the list of next buffers was to give the user a tool to undo
overshooting navigation of the list of previous buffers.  That is, when
I try to go back to a previous buffer and go too far, I can rescind that
step by going to the next buffer.

I don't know whether windows' buffer lists _should_ be different from
`buffer-list' and `buried-buffer-list'.  Intuitively, I'd agree that
they shouldn't.  For the moment suffice it to say that the global buffer
lists are not updated after `set-window-buffer', hence they are not
suitable for this kind of job.  But if you have an idea how to uniquify
these lists I'd be all ears.

Finally note that I do not consider the current behavior inconsistent.
The behavior of Emacs differs wrt browsers because it can switch to a
previous buffer with and without burying the present one.  The concept
of burying does not exist with browsers, IIUC.  The concept of showing
some reasonably useful buffer instead of a killed one either.  And from
my personal experience I can tell that making Firefox's TabMixPlus always
do what I mean in a specific context is virtually impossible.

Maybe we should really try to implement these lists with the help of
chronologially sortable Tabs and look at how the visual change after
each of the relevant Emacs operation affects the order of these Tabs.

martin

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.