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

 >>    (defcustom switch-to-prev-buffer-wrap nil
 >>      "Non-nil means switching to previous or next buffers behaves specially.
 >>    If this is non-nil, the commands `switch-to-prev-buffer' and
 >>    `switch-to-next-buffer' restrict their lists of candidate buffers
 >>    to those that were previously visible in the window specified by
 >>    their WINDOW argument.  Buffers never shown in that window are
 >>    ignored.
 >>
 >>    If this is t, candidate buffers form a ring and these commands
 >>    will always show another buffer, provided there are at least two
 >>    candidates.  If this is the symbol 'stop', these commands will
 >>    stop to show another buffer when reaching the first or last
 >>    candidate buffer.
 >>
 >>    If this option is nil or the argument BURY-OR-KILL of
 >>    `switch-to-prev-buffer' or `switch-to-next-buffer' is non-nil,
 >>    these commands may choose a buffer never shown in that window
 >>    before."
 >
 > The only problem is that this doesn't mention wrapping.

Isn't the paragraph starting with "If this is t, ..." enough?

 >> But I still think that the '-wrap' postfix creates a misnomer.  The
 >> primary intention of this option is to restrict the set of candidate
 >> buffers ...
 >
 > The real misnomer is 'tab-line-switch-cycling'.
 > It should be renamed 'tab-line-switch-wrap'.

For me "cycling" and "wrapping" stand for the same effect.  The major
difference is that when the above option is made non-nil, the set of
candidate buffers changes.  OTOH, when it's nil, Emacs wraps/cycles
while when it's 'stop' it doesn't.  That's confusing.

martin