all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Juri Linkov <juri@linkov.net>
To: martin rudalics <rudalics@gmx.at>
Cc: 69993@debbugs.gnu.org
Subject: bug#69993: Wrap window buffers while cycling
Date: Wed, 10 Apr 2024 20:45:30 +0300	[thread overview]
Message-ID: <86o7ahglre.fsf@mail.linkov.net> (raw)
In-Reply-To: <d8eea6ad-598d-4c77-8ddb-f8ab52f804bb@gmx.at> (martin rudalics's message of "Wed, 10 Apr 2024 10:46:48 +0200")

> Suppose I'm at the first element of a tab list.  With wrapping/cycling
> 'switch-to-prev-buffer' will select some buffer and that buffer will be
> shown as current in the tab list.

The selected buffer will be the first element of a tab list, not the last
as wrapping should do.  So currently 'switch-to-prev-buffer' doesn't do
wrapping.  Before 'switch-to-prev-buffer' the leftmost tab is selected,
and after 'switch-to-prev-buffer' the leftmost tab will remain selected.
Whereas the proper wrapping should select the rightmost tab/buffer.

> With restricting it will be the last element of the tab list, without
> restricting it may be a buffer that's new on the tab list, probably
> shown at its beginning.

When a buffer not previously displayed in the window appears at the
beginning, this is not wrapping.  Also when all available buffers were
already displayed in the window, and so restriction has no effect,
and an already displayed buffer appears at the beginning, this is
not wrapping too.

> Since 'tab-line-switch-to-prev-tab' restricts by default, it will
> always select the last buffer on the tab list.  What am I missing?

Unfortunately 'tab-line-switch-to-prev-tab' doesn't restrict by default.
This is a big problem for users that needs to be fixed.  Therefore
the wrapping option was proposed either for 'switch-to-prev-buffer'
or for 'tab-line-switch-to-prev-tab'.

>>> 'tab-line-switch-cycling' could then be used to override the more
>>> general 'switch-to-prev-buffer-wrap' when calling
>>> 'tab-line-switch-to-prev-tab'.  Or we could alias
>>> 'tab-line-switch-cycling' to 'switch-to-prev-buffer-wrap'.  And we could
>>> use the term 'switch-to-prev-buffer-cycle' instead.
>>
>> I think "cycle" is a wrong name.  Cycling is using
>> 'switch-to-prev-buffer'.  But wrapping is going
>> from the beginning to the end of the tab-line.
>
> In my understanding, the elements of the tab line are a visual
> representation of a "window-local" subset of all buffers.  This subset
> is ordered in a way that does not necessarily match the order used by
> 'switch-to-prev-buffer' - when C-x b-ing to a buffer already on the tab
> line, the tab line order does not change while the order of buffers used
> by C-x <left> and C-x <right> may change.  Other than that, cycling and
> wrapping behave identically wrt their respective sets.

By default the tab-line uses the order of window prev/next buffers.
So maybe it would be easier to keep the order in tab-line.el.

>> Mixing wrapping/cycling and restricting is unavoidable:
>> you can see how the previous patch reorders prev/next buffers
>> to make the order of tabs stay the same after wrapping.
>
> The order of tabs is one thing, that of buffers on the buffer list
> another and that of buffers to be visited by 'switch-to-prev-buffer' and
> 'switch-to-next-buffer' a third one.

Currently the first thing is the same as the third thing,
and this works fine.





  reply	other threads:[~2024-04-10 17:45 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-25  7:42 bug#69993: Wrap window buffers while cycling Juri Linkov
2024-03-25  9:41 ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-25 17:16   ` Juri Linkov
2024-03-26  9:56     ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-27  7:20       ` Juri Linkov
2024-03-27  8:48         ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-28  7:54           ` Juri Linkov
2024-03-28  9:19             ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-28 17:57               ` Juri Linkov
2024-03-29  8:45                 ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-29 16:35                   ` Juri Linkov
2024-03-30  9:37                     ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-30 18:24                       ` Juri Linkov
2024-03-31  8:32                         ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-02  6:37                           ` Juri Linkov
2024-04-02  8:22                             ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-02 16:28                               ` Juri Linkov
2024-04-03  8:24                                 ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-03 17:45                                   ` Juri Linkov
2024-04-04  8:03                                     ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-05  6:45                                       ` Juri Linkov
2024-04-05  9:08                                         ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-05 16:32                                           ` Juri Linkov
2024-04-06 18:43                                             ` Juri Linkov
2024-04-07  8:23                                               ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-09  6:35                                                 ` Juri Linkov
2024-04-09  9:04                                                   ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-09 16:37                                                     ` Juri Linkov
2024-04-10  8:46                                                       ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-10 17:45                                                         ` Juri Linkov [this message]
2024-04-11  9:18                                                           ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-12  6:35                                                             ` Juri Linkov
2024-04-12  8:37                                                               ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-12 16:23                                                                 ` Juri Linkov
2024-04-14 16:15                                                                   ` Juri Linkov
2024-04-16  6:38                                                                     ` Juri Linkov
2024-04-17 17:56                                                                       ` Juri Linkov
2024-04-24 16:39                                                                         ` Juri Linkov
2024-04-25  8:31                                                                           ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-25 17:40                                                                             ` Juri Linkov
2024-04-02 16:34                               ` Juri Linkov
2024-04-03  8:24                                 ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-03 17:44                                   ` Juri Linkov
2024-04-04  6:22                                 ` Juri Linkov
2024-04-02 16:40                               ` Juri Linkov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=86o7ahglre.fsf@mail.linkov.net \
    --to=juri@linkov.net \
    --cc=69993@debbugs.gnu.org \
    --cc=rudalics@gmx.at \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.