From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Juri Linkov Newsgroups: gmane.emacs.bugs Subject: bug#69993: Wrap window buffers while cycling Date: Wed, 10 Apr 2024 20:45:30 +0300 Organization: LINKOV.NET Message-ID: <86o7ahglre.fsf@mail.linkov.net> References: <86h6gug41x.fsf@mail.linkov.net> <86v855ggkv.fsf@mail.linkov.net> <91327e7b-d0a5-4f3a-a1f8-218d118608d6@gmx.at> <86sf07bnl4.fsf@mail.linkov.net> <86v850jmmo.fsf@mail.linkov.net> <0d2fdebf-2149-4f92-89b8-45a8b6a7d272@gmx.at> <86plv8hz2v.fsf@mail.linkov.net> <8a131d8b-1330-4d82-92f6-309f499e9c15@gmx.at> <86h6gi49zw.fsf@mail.linkov.net> <1e50bd70-8cbb-46f9-9078-dd0e6226da63@gmx.at> <861q7k8gms.fsf@mail.linkov.net> <2d3f0d14-e39b-4399-be30-03f11725c505@gmx.at> <86ttkf6a8r.fsf@mail.linkov.net> <86jzlajpqq.fsf@mail.linkov.net> <85109880-3370-47e0-b7c9-6c5a32cfaafa@gmx.at> <86le5nhwqy.fsf@mail.linkov.net> <864jcajzxi.fsf@mail.linkov.net> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="21695"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/30.0.50 (x86_64-pc-linux-gnu) Cc: 69993@debbugs.gnu.org To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Apr 10 20:04:35 2024 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1rucJG-0005Wq-Vd for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 10 Apr 2024 20:04:34 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rucIl-0008LY-1n; Wed, 10 Apr 2024 14:04:03 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rucIf-0008KX-EV for bug-gnu-emacs@gnu.org; Wed, 10 Apr 2024 14:03:59 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1rucIb-0004XM-TS for bug-gnu-emacs@gnu.org; Wed, 10 Apr 2024 14:03:56 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rucIk-0001r0-Ja for bug-gnu-emacs@gnu.org; Wed, 10 Apr 2024 14:04:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Juri Linkov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 10 Apr 2024 18:04:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 69993 X-GNU-PR-Package: emacs Original-Received: via spool by 69993-submit@debbugs.gnu.org id=B69993.17127721956569 (code B ref 69993); Wed, 10 Apr 2024 18:04:02 +0000 Original-Received: (at 69993) by debbugs.gnu.org; 10 Apr 2024 18:03:15 +0000 Original-Received: from localhost ([127.0.0.1]:54331 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rucHy-0001hn-Va for submit@debbugs.gnu.org; Wed, 10 Apr 2024 14:03:15 -0400 Original-Received: from relay5-d.mail.gandi.net ([217.70.183.197]:46861) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rucHo-0001eX-1u for 69993@debbugs.gnu.org; Wed, 10 Apr 2024 14:03:06 -0400 Original-Received: by mail.gandi.net (Postfix) with ESMTPSA id E19451C0004; Wed, 10 Apr 2024 18:02:48 +0000 (UTC) In-Reply-To: (martin rudalics's message of "Wed, 10 Apr 2024 10:46:48 +0200") X-GND-Sasl: juri@linkov.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:283058 Archived-At: > 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 and C-x 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.