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

Previous Next

Package: emacs;

Reported by: Juri Linkov <juri <at> jurta.org>

Date: Thu, 13 Dec 2012 00:03:02 UTC

Severity: minor

Found in version 24.3.50

Full log


View this message in rfc822 format

From: Juri Linkov <juri <at> jurta.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 13167 <at> debbugs.gnu.org
Subject: bug#13167: 24.3.50; C-x right C-x left interferes with buffer order
Date: Sat, 22 Dec 2012 11:27:50 +0200
>> 12. q   the last q doesn't restore the initial buffer *scratch*
>
> Is the list of previous buffers empty in step 12 ?

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

> Then we could heuristically show the last buffer added to the list of
> next buffers here.  Preferring a buffer which is not on any of this
> window's lists doesn't make much sense in this case, I think.
>
> I guess that this scenario would also break the recipe you proposed
> earlier, namely to keep next and previous buffers as lists built from
> elements of the same type and not choose an element from the next
> buffers when quitting.

Yes, such change will break this scenario.

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.




This bug report was last modified 1 year and 156 days ago.

Previous Next


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