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: Tue, 09 Apr 2024 19:37:50 +0300 Organization: LINKOV.NET Message-ID: <864jcajzxi.fsf@mail.linkov.net> References: <86h6gug41x.fsf@mail.linkov.net> <463c9242-56ef-4c99-9fe6-4b70be2071b2@gmx.at> <86sf0abeg3.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> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="1379"; 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 Tue Apr 09 18:51:05 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 1ruEgb-00009a-47 for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 09 Apr 2024 18:51:05 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ruEej-0006jZ-So; Tue, 09 Apr 2024 12:49:16 -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 1ruEda-00066W-RF for bug-gnu-emacs@gnu.org; Tue, 09 Apr 2024 12:48:03 -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 1ruEdZ-00011g-Lx for bug-gnu-emacs@gnu.org; Tue, 09 Apr 2024 12:47:58 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ruEdh-00011d-OM for bug-gnu-emacs@gnu.org; Tue, 09 Apr 2024 12:48:05 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Juri Linkov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 09 Apr 2024 16:48:05 +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.17126812563710 (code B ref 69993); Tue, 09 Apr 2024 16:48:05 +0000 Original-Received: (at 69993) by debbugs.gnu.org; 9 Apr 2024 16:47:36 +0000 Original-Received: from localhost ([127.0.0.1]:51314 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ruEdE-0000xm-9O for submit@debbugs.gnu.org; Tue, 09 Apr 2024 12:47:36 -0400 Original-Received: from relay8-d.mail.gandi.net ([2001:4b98:dc4:8::228]:47997) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ruEdB-0000wj-DY for 69993@debbugs.gnu.org; Tue, 09 Apr 2024 12:47:33 -0400 Original-Received: by mail.gandi.net (Postfix) with ESMTPSA id EE37C1BF206; Tue, 9 Apr 2024 16:47:17 +0000 (UTC) In-Reply-To: (martin rudalics's message of "Tue, 9 Apr 2024 11:04:38 +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:283002 Archived-At: >> The problem is that from the point of view of tab-line users >> currently there is no wrapping because the tab-line already >> restricts itself to the buffers shown in that window only. > > I'm afraid we still misunderstand each other: For me "wrap" means that > when I'm at the beginning of a list and want to go to its previous > element, I go to the last element of the list. When I'm at the end of a > list and want to go to its next element, I go to the first element of > the list. > > I think that if we added a 'switch-to-prev-buffer-wrap' option, we would > emulate the behavior sketched above regardless of whether it's triggered > by 'switch-to-prev-buffer' or 'tab-line-switch-to-prev-tab'. Currently, > 'switch-to-prev-buffer' always wraps while 'tab-line-switch-to-prev-tab' > obeys the value of 'tab-line-switch-cycling'. The users won't understand how currently 'switch-to-prev-buffer' always wraps, when going to the previous element at the beginning of a list doesn't go to the last element of the tab-line. > '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. >> But if you think that 'switch-to-prev-buffer-wrap' should be renamed >> to something that makes no sense for tab-line users such as >> 'switch-to-prev-buffer-restrict', then still it can be used >> from tab-line.el like this: >> >> (when tab-line-switch-cycling >> (let-bind ((switch-to-prev-buffer-restrict tab-line-switch-cycling)) >> (switch-to-prev-buffer window))) > > An option like say 'switch-to-prev-buffer-restrict' should effectively > affect 'switch-to-prev-buffer' only. 'tab-line-switch-to-prev-tab' > would not switch to a buffer never shown in that window and could be > implemented as you sketched above. > > To sum up, I think that we should not mingle the concepts of > wrapping/cycling and restricting into one and the same option but > provide two options instead. 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.