bug#69993: Wrap window buffers while cycling

[martin rudalics via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

 > I see that the Elisp manual also says about 'switch-to-prev-buffer':
 >
 >   -- Command: bury-buffer &optional buffer-or-name
 >       ...
 >       (*note Quitting Windows::).  Otherwise, it calls
 >       ‘switch-to-prev-buffer’ (*note Window History::)
 >       to show another buffer in that window.
 >
 > This means that it reuses switch-to-prev-buffer to show any available
 > buffer, even the buffers that were never shown in that window.

Even buffers that were never shown anywhere.  That's the way Emacs
traditionally behaves and we are not supposed to change that.

 > This means that such calls should be wrapped with let-bind
 > to handle the case when the list of prev/next-buffers becomes empty
 > to switch to any other buffer not shown in that window before:
 >
 > @@ -4994,7 +5042,8 @@ bury-buffer
 >        (t
 >         ;; Switch to another buffer in window.
 >         (set-window-dedicated-p nil nil)
 > -      (switch-to-prev-buffer nil 'bury)))
 > +      (let ((switch-to-prev-buffer-wrap nil))
 > +        (switch-to-prev-buffer nil 'bury))))
 >       ;; Always return nil.
 >       nil))

You mean to avoid a "Could not replace buffer ..." error?  Can't we
handle this problem in 'switch-to-prev-buffer' when BURY-OR-KILL and
'switch-to-prev-buffer-wrap' are non-nil, here and in the other calls
you cite?

 > 'C-x b' is not different from 'C-x <left>' and 'C-x <right>'
 > when the buffer selected for 'C-x b' was already shown in the window.

But then we would have to handle any call of set_window_buffer that
replaces a window's buffer with one that has been previously shown in
that window.  Think only of 'switch-to-buffer-obey-display-actions'.

 >> I think the following is problematic:
 >>
 >>    (defun tab-line-switch-to-prev-tab (&optional event)
 >>      "Switch to the previous tab's buffer.
 >>    Its effect is the same as using the `previous-buffer' command
 >>    (\\[previous-buffer])."
 >>
 >> If the "previous tab" does not show the buffer 'switch-to-prev-buffer'
 >> would switch to, then the doc is wrong.  I'm not sure whether
 >> 'tab-line-tabs-window-buffers' can guarantee that this chooses the same
 >> buffer 'switch-to-prev-buffer' would switch to, though.  If it doesn't,
 >> then the effect should be that of C-x b switching to a buffer earlier
 >> shown in that window.  BTW, burying a buffer removes it from the tab
 >> line but does not prevent 'switch-to-prev-buffer' from switching to it -
 >> it just makes it very unlikely IIRC.
 >
 > tab-line-switch-to-prev-tab doesn't choose buffers itself:
 > for tab-line-tabs-window-buffers it just delegates the task
 > to switch-to-prev-buffer.

But what is the "previous tab"?  IIUC it is the one on the left of the
current tab in the tab line.  But that tab is not necessarily the one
'switch-to-prev-buffer' will switch to.

martin