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

[Juri Linkov <juri@jurta.org>]

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