bug#69993: Wrap window buffers while cycling

[martin rudalics]

> There is a remaining problem, and I can't find a way to fix it.
> When a buffer already appeared in the window before,
> then switching to that buffer with e.g. 'C-x b'
> moves it to the end of the list.  Technically
> this means that window-next-buffers is set to nil.

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.

> However, I can't find code that does this.  Could you help
> to find it?  I already found one occurrence of
> (set-window-next-buffers window nil) in record-window-buffer.
> But after adding a condition with switch-to-prev-buffer-wrap
> it still moves the switched buffer to the end.

If you get me the patch you currently use and a scenario, I'll try.

martin