bug#13167: 24.3.50; C-x right C-x left interferes with buffer order

bug#13167: 24.3.50; C-x right C-x left interferes with buffer order

[Juri Linkov]

There is something in quit-window and the buffer order
that looks like a regression, but I'm not sure what.
Please dismiss this bug report if there is nothing wrong.

1. emacs -Q
2. C-h C-n       visits NEWS
3. C-x d RET     visits Dired in the directory `etc'
4. v             visits first file in the directory `etc'
5. q
6. q
7. q

Every subsequent `q' restores the previous buffer.
This is correct.

But when this sequence is interspersed with seemingly idempotent
`C-x right C-x left', the buffer order becomes broken:

1. emacs -Q
2. C-h C-n
3. C-x d RET
4. v
5. C-x right   (or C-h e for the same effect)
6. C-x left
7. q

Then `q' displays the buffer `*Messages*' instead of the expected
previous Dired buffer `etc'.  Typing `C-x left' displays it,
but then another `q' displays the buffer `*Messages*' again.

8. C-x left
9. q

Again `*Messages*' instead of the expected NEWS.

10. C-x left
11. q

And again `*Messages*' instead of the expected *scratch*.

So the question is why `*Messages*' gets in the way
in the list of previous buffers.

bug#13167: 24.3.50; C-x right C-x left interferes with buffer order

[martin rudalics]

 > 1. emacs -Q
 > 2. C-h C-n
 > 3. C-x d RET
 > 4. v
 > 5. C-x right   (or C-h e for the same effect)

`next-buffer' picks a buffer that's not in the window's list of previous
buffers.

 > 6. C-x left

`previous-buffer' picks the buffer that was shown in the window before
the current buffer.

 > 7. q
 >
 > Then `q' displays the buffer `*Messages*' instead of the expected
 > previous Dired buffer `etc'.

This is from the doc-string of `quit-window':

   (3) restore the buffer previously displayed in WINDOW,

which is *Messages*.

 > Typing `C-x left' displays it,
 > but then another `q' displays the buffer `*Messages*' again.
 >
 > 8. C-x left
 > 9. q
 >
 > Again `*Messages*' instead of the expected NEWS.

Again according to the doc-string.

 > 10. C-x left
 > 11. q
 >
 > And again `*Messages*' instead of the expected *scratch*.
 >
 > So the question is why `*Messages*' gets in the way
 > in the list of previous buffers.

Simply because it is the last buffer displayed in that window before the
one you quit.  That's how it was designed and I'm not sure whether we
can do much better.  Why do you never quit the *Messages* buffer in your
scenario?  The semantics of C-x left and C-x right is that you want (or
at least don't mind) to switch back to the old buffer.  The semantics of
`quit-window' is that you don't want to switch back to the old buffer
soon.

martin

bug#13167: 24.3.50; C-x right C-x left interferes with buffer order

[Juri Linkov]

> Why do you never quit the *Messages* buffer in your scenario?

I can't quit the *Messages* buffer.  Typing `q' inserts the character
`q' to the *Messages* buffer.  But it's good that *Messages* is writable.
The same problem can occur with any other writable buffer.

> The semantics of C-x left and C-x right is that you want (or
> at least don't mind) to switch back to the old buffer.

Typing `C-x left' in the *Messages* buffer in the aforementioned scenario adds
the *Messages* buffer to both (window-prev-buffers) and to (window-next-buffers).
This looks doubtful.  Is this intentional?

> The semantics of `quit-window' is that you don't want to switch back
> to the old buffer soon.

I thought that when a buffer is displayed for the first time
(e.g. with `C-h C-n', or `v' in Dired mode), it sets up `quit-window',
so `q' will be able to return to the buffer that initiated its display.
I didn't expect that `C-x right C-x left' affects `quit-window'.

bug#13167: 24.3.50; C-x right C-x left interferes with buffer order

[martin rudalics]

 >> Why do you never quit the *Messages* buffer in your scenario?
 >
 > I can't quit the *Messages* buffer.  Typing `q' inserts the character
 > `q' to the *Messages* buffer.  But it's good that *Messages* is writable.
 > The same problem can occur with any other writable buffer.

You can always do M-x quit-window.  Isn't there some C-x binding we
could use for this?

 >> The semantics of C-x left and C-x right is that you want (or
 >> at least don't mind) to switch back to the old buffer.
 >
 > Typing `C-x left' in the *Messages* buffer in the aforementioned scenario adds
 > the *Messages* buffer to both (window-prev-buffers) and to (window-next-buffers).
 > This looks doubtful.  Is this intentional?

Yes.  When in `switch-to-next-buffer'

       (dolist (buffer next-buffers)
	(when (and (or (buffer-live-p buffer)
		       (not (setq killed-buffers
				  (cons buffer killed-buffers))))
		   (not (eq buffer old-buffer))
                    (or (null pred) (funcall pred buffer))
		   (setq entry (assq buffer (window-prev-buffers window))))
	  (setq new-buffer buffer)
	  (set-window-buffer-start-and-point
	   window new-buffer (nth 1 entry) (nth 2 entry))
	  (throw 'found t)))

this loop finds a buffer to switch to, it retrieves the start and point
positions from the buffer's association in the window's _previous_
buffers.  I didn't want to maintain the same markers twice.

 > I thought that when a buffer is displayed for the first time
 > (e.g. with `C-h C-n', or `v' in Dired mode), it sets up `quit-window',
 > so `q' will be able to return to the buffer that initiated its display.

The dichotomy striking here is rooted in the history of `quit-window'
which was used (via "q") for getting rid of temporary, typically
read-only buffers, but also for generally getting rid of a window's
contents.

 > I didn't expect that `C-x right C-x left' affects `quit-window'.

They both affect each other.  If there's no explicit `quit-restore'
parameter, `quit-window' uses whatever `window-prev-buffers' provides.
And quitting a window should make its buffer move to the far ends of its
previous and next buffers.

martin

bug#13167: 24.3.50; C-x right C-x left interferes with buffer order

[Juri Linkov]

>>> Why do you never quit the *Messages* buffer in your scenario?
>>
>> I can't quit the *Messages* buffer.  Typing `q' inserts the character
>> `q' to the *Messages* buffer.  But it's good that *Messages* is writable.
>> The same problem can occur with any other writable buffer.
>
> You can always do M-x quit-window.  Isn't there some C-x binding we
> could use for this?

A good C-x binding for quit-window is `C-x q'.  Its current command
does nothing normally and already has an alternative keybinding
`C-x C-k q' while recording a macro.

> this loop finds a buffer to switch to, it retrieves the start and point
> positions from the buffer's association in the window's _previous_
> buffers.  I didn't want to maintain the same markers twice.

To not maintain the same markers twice, `C-x left' could add the
current buffer with markers only once to the list of next buffers,
but not to the list of previous buffers.  Do I miss something
why this won't work?

bug#13167: 24.3.50; C-x right C-x left interferes with buffer order

[martin rudalics]

 > A good C-x binding for quit-window is `C-x q'.  Its current command
 > does nothing normally and already has an alternative keybinding
 > `C-x C-k q' while recording a macro.

It's easy to convince me ...

 >> this loop finds a buffer to switch to, it retrieves the start and point
 >> positions from the buffer's association in the window's _previous_
 >> buffers.  I didn't want to maintain the same markers twice.
 >
 > To not maintain the same markers twice, `C-x left' could add the
 > current buffer with markers only once to the list of next buffers,
 > but not to the list of previous buffers.  Do I miss something
 > why this won't work?

If we did that, we'd probably get rid of the behavior you started this
thread with.  But the current semantics is "when we have to replace a
buffer in a window with another one, try taking the buffer that has been
shown in that window before the present one".  I'm not quite sure how to
describe what you want to do instead.

martin

bug#13167: 24.3.50; C-x right C-x left interferes with buffer order

[Juri Linkov]

>> To not maintain the same markers twice, `C-x left' could add the
>> current buffer with markers only once to the list of next buffers,
>> but not to the list of previous buffers.  Do I miss something
>> why this won't work?
>
> If we did that, we'd probably get rid of the behavior you started this
> thread with.  But the current semantics is "when we have to replace a
> buffer in a window with another one, try taking the buffer that has been
> shown in that window before the present one".  I'm not quite sure how to
> describe what you want to do instead.

I think that C-x right and C-x left should behave like the "Next" and
"Prev" buttons in a browser where clicking the "Next" button adds the
current page to the list of previous pages, removes the first page from
the list of next pages and displays it.  Clicking the "Prev" button adds
the current page to the list of next pages, removes the first page from
the list of previous pages and displays it.

It's disturbing that such unobtrusive action can mislead quit-window
to restore a buffer that was only temporarily shown in that window
with C-x right C-x left.  I believe C-x right and C-x left should be
special to not affect the logic of "try taking the buffer that has been
shown in that window before the present one".

bug#13167: 24.3.50; C-x right C-x left interferes with buffer order

[martin rudalics]

 > I think that C-x right and C-x left should behave like the "Next" and
 > "Prev" buttons in a browser where clicking the "Next" button adds the
 > current page to the list of previous pages, removes the first page from
 > the list of next pages and displays it.  Clicking the "Prev" button adds
 > the current page to the list of next pages, removes the first page from
 > the list of previous pages and displays it.

Virtually, that's what the code does.

 > It's disturbing that such unobtrusive action can mislead quit-window
 > to restore a buffer that was only temporarily shown in that window
 > with C-x right C-x left.

But the buffer shown via C-x right might have been shown there for quite
some while.

 > I believe C-x right and C-x left should be
 > special to not affect the logic of "try taking the buffer that has been
 > shown in that window before the present one".

I'm not sure what this means to do instead.  Have `quit-window' not show
a buffer if it appears on `window-next-buffers'?  What happens if you
turn the form

		   (or bury-or-kill (not (memq buffer next-buffers))))

in `switch-to-prev-buffer' into

		   (not (memq buffer next-buffers)))

I have no idea what else this could affect, though.

martin

bug#13167: 24.3.50; C-x right C-x left interferes with buffer order

[Juri Linkov]

>> I believe C-x right and C-x left should be special to not affect the
>> logic of "try taking the buffer that has been shown in that window
>> before the present one".
>
> I'm not sure what this means to do instead.  Have `quit-window' not show
> a buffer if it appears on `window-next-buffers'?

Thanks, this sounds right.

> What happens if you turn the form
>
> 		   (or bury-or-kill (not (memq buffer next-buffers))))
>
> in `switch-to-prev-buffer' into
>
> 		   (not (memq buffer next-buffers)))

I tried to do this but with no effect.  Then I also turned

		   (or bury-or-kill (not (memq new-buffer next-buffers))))

in `switch-to-prev-buffer' into

		   (not (memq new-buffer next-buffers)))

and it works as expected.  Not sure about possible side-effects,
have to test this change more.

bug#13167: 24.3.50; C-x right C-x left interferes with buffer order

[Juri Linkov]

> in `switch-to-prev-buffer' into
>
> 		   (not (memq new-buffer next-buffers)))
>
> and it works as expected.  Not sure about possible side-effects,
> have to test this change more.

There is one side-effect with overwrapping in next buffers.
When `C-x right C-x right' wraps to the first buffer *scratch*,
*scratch* is pushed to the list of next buffers.

Then `C-x left C-x left' returns to the previous buffers,
typing `q' restores the right buffer, another `q' restores
another right buffer.  But the last `q' doesn't restore
the buffer *scratch*.

This is in the following scenario:

 1. emacs -Q
 2. C-h C-n
 3. C-x d RET
 4. v
 5. C-x right    displays the buffer *Messages*
 6. C-x right    displays the buffer *scratch*
 7. C-x left
 8. C-x left
 9. q
10. q
11. q
12. q   the last q doesn't restore the initial buffer *scratch*

bug#13167: 24.3.50; C-x right C-x left interferes with buffer order

[martin rudalics]

 > There is one side-effect with overwrapping in next buffers.
 > When `C-x right C-x right' wraps to the first buffer *scratch*,
 > *scratch* is pushed to the list of next buffers.
 >
 > Then `C-x left C-x left' returns to the previous buffers,
 > typing `q' restores the right buffer, another `q' restores
 > another right buffer.  But the last `q' doesn't restore
 > the buffer *scratch*.
 >
 > This is in the following scenario:
 >
 >  1. emacs -Q
 >  2. C-h C-n
 >  3. C-x d RET
 >  4. v
 >  5. C-x right    displays the buffer *Messages*
 >  6. C-x right    displays the buffer *scratch*
 >  7. C-x left
 >  8. C-x left
 >  9. q
 > 10. q
 > 11. q
 > 12. q   the last q doesn't restore the initial buffer *scratch*

Is the list of previous buffers empty in step 12 ?  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.

martin

bug#13167: 24.3.50; C-x right C-x left interferes with buffer order

[Juri Linkov]

>> 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.

bug#13167: 24.3.50; C-x right C-x left interferes with buffer order

[martin rudalics]

 > 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

bug#13167: 24.3.50; C-x right C-x left interferes with buffer order

[Juri Linkov]

> The concept of burying does not exist with browsers, IIUC.

I don't see something analogous in browsers too, but in Emacs
for frame-local buffer lists, burying implies a ring structure
(a circular list) where popping the first buffer from the top of
the ring pushes it to the bottom.  It seems that reported problems are
caused by the fact that window-local buffers don't form a circular ring.

> 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.

Firefox's TabMixPlus provides 6 options to focus
after closing the current tab:

1. First tab
2. Left tab
3. Right tab
4. Last tab
5. Opener/right tab
6. Last opened tab

Currently `q' in Emacs performs the option 3 "Right tab" that means
to restore the last buffer in the list of previous buffer (or maybe it's
the option 6 "Last opened tab"?).  But I believe that more useful would be
the option 5 "Opener/right tab" where Opener means the buffer that
initially displayed the current buffer, so `q' should restore it.
If you disagree then maybe this should be configurable in Emacs?

bug#13167: 24.3.50; C-x right C-x left interferes with buffer order

[martin rudalics]

 > I don't see something analogous in browsers too, but in Emacs
 > for frame-local buffer lists, burying implies a ring structure
 > (a circular list) where popping the first buffer from the top of
 > the ring pushes it to the bottom.  It seems that reported problems are
 > caused by the fact that window-local buffers don't form a circular ring.

A circular ring doesn't work here.  When I create a new window I have to
feed `switch-to-prev-buffer' and `switch-to-next-buffer' with the
buffers from the frame's and/or the global buffer list.  That's what
users expect from the old behavior which IIRC used `other-buffer' for
this purpose.  And I have to continue to do that whenever I'm at the end
of the lists of a window's previous and next buffers.

 > Firefox's TabMixPlus provides 6 options to focus
 > after closing the current tab:
 >
 > 1. First tab
 > 2. Left tab
 > 3. Right tab
 > 4. Last tab
 > 5. Opener/right tab
 > 6. Last opened tab
 >
 > Currently `q' in Emacs performs the option 3 "Right tab" that means
 > to restore the last buffer in the list of previous buffer (or maybe it's
 > the option 6 "Last opened tab"?).

I think it's 6 which is the only navigation-sensitive option.

All other options remember only the creation time of tabs and disregard
navigation.

 > But I believe that more useful would be
 > the option 5 "Opener/right tab" where Opener means the buffer that
 > initially displayed the current buffer, so `q' should restore it.
 > If you disagree then maybe this should be configurable in Emacs?

This might be a good idea.  BTW I'm using option 5 on Firefox and at
least 20 times a day I'm profoundly unhappy with it.  I already wonder
whether the behavior I'd prefer is "Opener/Last opened tab".

But it's not easy to compare Firefox tabs to our windows' buffer lists.
In particular when you open links in the background like me.

martin

bug#13167: 24.3.50; C-x right C-x left interferes with buffer order

[Juri Linkov]

>>> Why do you never quit the *Messages* buffer in your scenario?
>>
>> I can't quit the *Messages* buffer.  Typing `q' inserts the character
>> `q' to the *Messages* buffer.  But it's good that *Messages* is writable.
>> The same problem can occur with any other writable buffer.
>
> You can always do M-x quit-window.  Isn't there some C-x binding we
> could use for this?

Now that we have new key prefixes: 'C-x x' for buffer commands, and
'C-x w' for window commands, probably the most suitable key would be
'C-x w q' for 'quit-window'.

bug#13167: 24.3.50; C-x right C-x left interferes with buffer order

[martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors]

 > Now that we have new key prefixes: 'C-x x' for buffer commands, and
 > 'C-x w' for window commands, probably the most suitable key would be
 > 'C-x w q' for 'quit-window'.

I think it can't harm to use that.

martin

bug#13167: 24.3.50; C-x right C-x left interferes with buffer order

[Juri Linkov]

>> Now that we have new key prefixes: 'C-x x' for buffer commands, and
>> 'C-x w' for window commands, probably the most suitable key would be
>> 'C-x w q' for 'quit-window'.
>
> I think it can't harm to use that.

Ok, then I'm going to install this patch in master:

diff --git a/lisp/window.el b/lisp/window.el
index 5c3e68f04eb..f097a027892 100644
--- a/lisp/window.el
+++ b/lisp/window.el
@@ -10815,7 +10816,8 @@ window-prefix-map
   "^ f" #'tear-off-window
   "^ t" #'tab-window-detach
   "-" #'fit-window-to-buffer
-  "0" #'delete-windows-on)
+  "0" #'delete-windows-on
+  "q" #'quit-window)
 (define-key ctl-x-map "w" window-prefix-map)

I can't find the global quit-window in the Emacs manual
to document a new keybinding.  But I found that many 'C-x x'
keybindings are not yet documented.

Eli, do you agree to install the following patch in the emacs-29 branch?

diff --git a/doc/emacs/buffers.texi b/doc/emacs/buffers.texi
index 8b093078edd..80e552fa46a 100644
--- a/doc/emacs/buffers.texi
+++ b/doc/emacs/buffers.texi
@@ -262,12 +262,14 @@ Misc Buffer
 non-@code{nil} value, making the buffer read-only with @kbd{C-x C-q}
 also enables View mode in the buffer (@pxref{View Mode}).
 
+@kindex C-x x r
 @findex rename-buffer
   @kbd{C-x x r} (@code{rename-buffer} changes the name of the current
 buffer.  You specify the new name as a minibuffer argument; there is
 no default.  If you specify a name that is in use for some other
 buffer, an error happens and no renaming is done.
 
+@kindex C-x x u
 @findex rename-uniquely
   @kbd{C-x x u} (@code{rename-uniquely}) renames the current buffer to
 a similar name with a numeric suffix added to make it both different
@@ -282,6 +284,7 @@ Misc Buffer
 buffer before using the command again, otherwise it will reuse the
 current buffer despite the name change.)
 
+@kindex C-x x i
   The commands @kbd{M-x append-to-buffer} and @kbd{C-x x i}
 (@code{insert-buffer}) can also be used to copy text from one buffer
 to another.  @xref{Accumulating Text}.
diff --git a/doc/emacs/display.texi b/doc/emacs/display.texi
index e6a43bf74a8..6db9e8344c6 100644
--- a/doc/emacs/display.texi
+++ b/doc/emacs/display.texi
@@ -1986,6 +1986,7 @@ Line Truncation
 terminals, this is indicated with @samp{$} signs in the rightmost
 and/or leftmost columns.
 
+@kindex C-x x t
 @vindex truncate-lines
 @findex toggle-truncate-lines
   Horizontal scrolling automatically causes line truncation
diff --git a/doc/emacs/files.texi b/doc/emacs/files.texi
index 9c5305acf60..b152b7943a2 100644
--- a/doc/emacs/files.texi
+++ b/doc/emacs/files.texi
@@ -1061,6 +1061,7 @@ Reverting
 is not modified.  (If you have edited the text, it would be wrong to
 discard your changes.)
 
+@kindex C-x x g
 @vindex revert-buffer-quick-short-answers
 @findex revert-buffer-quick
   The @kbd{C-x x g} keystroke is bound to the
diff --git a/doc/emacs/windows.texi b/doc/emacs/windows.texi
index f1f7a5b4b86..935004edad3 100644
--- a/doc/emacs/windows.texi
+++ b/doc/emacs/windows.texi
@@ -287,7 +287,7 @@ Change Window
 Delete the selected window and kill the buffer that was showing in it
 (@code{kill-buffer-and-window}).  The last character in this key
 sequence is a zero.
-@item M-x delete-windows-on @key{RET} @var{buffer} @key{RET}
+@item C-x w d @key{RET} @var{buffer} @key{RET}
 Delete windows showing the specified @var{buffer}.
 @item C-x ^
 Make selected window taller (@code{enlarge-window}).
diff --git a/doc/misc/info.texi b/doc/misc/info.texi
index 31b314cb9a0..01c7f614e7d 100644
--- a/doc/misc/info.texi
+++ b/doc/misc/info.texi
@@ -1148,6 +1148,7 @@ Create Info buffer
 @section @kbd{M-n} creates a new independent Info buffer in Emacs
 
 @kindex M-n @r{(Info mode)}
+@kindex C-x x n
 @findex clone-buffer
 @cindex multiple Info buffers
   If you are reading Info in Emacs, you can select a new independent

bug#13167: 24.3.50; C-x right C-x left interferes with buffer order

[Eli Zaretskii]

> Cc: 13167@debbugs.gnu.org
> From: Juri Linkov <juri@jurta.org>
> Date: Fri, 12 Jan 2024 09:42:03 +0200
> 
> Eli, do you agree to install the following patch in the emacs-29 branch?

Yes, documentation improvements, including better indexing, are always
welcome on the release branch.

Thanks.

bug#13167: 24.3.50; C-x right C-x left interferes with buffer order

[Stefan Kangas]

Juri Linkov <juri@jurta.org> writes:

> There is something in quit-window and the buffer order
> that looks like a regression, but I'm not sure what.
> Please dismiss this bug report if there is nothing wrong.
>
> 1. emacs -Q
> 2. C-h C-n       visits NEWS
> 3. C-x d RET     visits Dired in the directory `etc'
> 4. v             visits first file in the directory `etc'
> 5. q
> 6. q
> 7. q
>
> Every subsequent `q' restores the previous buffer.
> This is correct.
>
> But when this sequence is interspersed with seemingly idempotent
> `C-x right C-x left', the buffer order becomes broken:
>
> 1. emacs -Q
> 2. C-h C-n
> 3. C-x d RET
> 4. v
> 5. C-x right   (or C-h e for the same effect)
> 6. C-x left
> 7. q
>
> Then `q' displays the buffer `*Messages*' instead of the expected
> previous Dired buffer `etc'.  Typing `C-x left' displays it,
> but then another `q' displays the buffer `*Messages*' again.
>
> 8. C-x left
> 9. q
>
> Again `*Messages*' instead of the expected NEWS.
>
> 10. C-x left
> 11. q
>
> And again `*Messages*' instead of the expected *scratch*.
>
> So the question is why `*Messages*' gets in the way
> in the list of previous buffers.

Ten years later, is still an issue on a modern version of Emacs?

bug#13167: 24.3.50; C-x right C-x left interferes with buffer order

[Juri Linkov]

>> 10. C-x left
>> 11. q
>>
>> And again `*Messages*' instead of the expected *scratch*.
>>
>> So the question is why `*Messages*' gets in the way
>> in the list of previous buffers.
>
> Ten years later, is still an issue on a modern version of Emacs?

Yes, and now some users of the tab-line complain about the same issue too.

So we need to add a new option to switch to the alternative behavior.