Juri Linkov <juri@HIDDEN>
to control <at> debbugs.gnu.org.
Full text available.Received: (at 69993) by debbugs.gnu.org; 17 Apr 2024 17:59:40 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Apr 17 13:59:40 2024 Received: from localhost ([127.0.0.1]:47235 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1rx9ZK-0006C7-R8 for submit <at> debbugs.gnu.org; Wed, 17 Apr 2024 13:59:40 -0400 Received: from relay9-d.mail.gandi.net ([2001:4b98:dc4:8::229]:44693) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <juri@HIDDEN>) id 1rx9ZE-0006AG-BP; Wed, 17 Apr 2024 13:59:37 -0400 Received: by mail.gandi.net (Postfix) with ESMTPSA id 21E50FF802; Wed, 17 Apr 2024 17:59:09 +0000 (UTC) From: Juri Linkov <juri@HIDDEN> To: martin rudalics <rudalics@HIDDEN> Subject: Re: bug#69993: Wrap window buffers while cycling In-Reply-To: <867cgxn7lx.fsf@HIDDEN> (Juri Linkov's message of "Tue, 16 Apr 2024 09:38:14 +0300") Organization: LINKOV.NET References: <86h6gug41x.fsf@HIDDEN> <86plv8hz2v.fsf@HIDDEN> <8a131d8b-1330-4d82-92f6-309f499e9c15@HIDDEN> <86h6gi49zw.fsf@HIDDEN> <1e50bd70-8cbb-46f9-9078-dd0e6226da63@HIDDEN> <861q7k8gms.fsf@HIDDEN> <2d3f0d14-e39b-4399-be30-03f11725c505@HIDDEN> <86ttkf6a8r.fsf@HIDDEN> <86jzlajpqq.fsf@HIDDEN> <85109880-3370-47e0-b7c9-6c5a32cfaafa@HIDDEN> <86le5nhwqy.fsf@HIDDEN> <f0a8c8ef-b722-4b62-ae17-c73cbef390ce@HIDDEN> <864jcajzxi.fsf@HIDDEN> <d8eea6ad-598d-4c77-8ddb-f8ab52f804bb@HIDDEN> <86o7ahglre.fsf@HIDDEN> <28a8149b-283a-4b08-9df5-f1139a0fccbe@HIDDEN> <86ttk7m7ir.fsf@HIDDEN> <1b38c78c-6697-4c6b-81cf-5a72fdd3ba8d@HIDDEN> <868r1i8si0.fsf@HIDDEN> <867ch09bx6.fsf@HIDDEN> <867cgxn7lx.fsf@HIDDEN> Date: Wed, 17 Apr 2024 20:56:59 +0300 Message-ID: <86zftrlvo4.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/30.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-GND-Sasl: juri@HIDDEN X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 69993 Cc: 69993 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.7 (-) close 69993 30.0.50 thanks > Actually using hooks as well as advices in core packages is not a nice > thing to do. Neither tab-bar.el nor tab-line.el uses hooks and advices. > Also better not to mess with set-window-prev-buffers. And this is > perfectly possible with the following small patch that supports > everything: wrapping, C-x <left>, C-x b, 'rename-buffer' with > buffers restricted to those that were displayed in the window > while keeping them in the fixed order: So now this is added to tab-line.el and closed. Thanks for helping to arrive at this solution.
bug-gnu-emacs@HIDDEN:bug#69993; Package emacs.
Full text available.
Received: (at 69993) by debbugs.gnu.org; 16 Apr 2024 06:42:33 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Apr 16 02:42:33 2024
Received: from localhost ([127.0.0.1]:41975 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1rwcWV-0003wQ-Vu
for submit <at> debbugs.gnu.org; Tue, 16 Apr 2024 02:42:33 -0400
Received: from relay9-d.mail.gandi.net ([2001:4b98:dc4:8::229]:41445)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <juri@HIDDEN>) id 1rwcWS-0003v8-PD
for 69993 <at> debbugs.gnu.org; Tue, 16 Apr 2024 02:42:30 -0400
Received: by mail.gandi.net (Postfix) with ESMTPSA id 7D2F1FF807;
Tue, 16 Apr 2024 06:42:10 +0000 (UTC)
From: Juri Linkov <juri@HIDDEN>
To: martin rudalics <rudalics@HIDDEN>
Subject: Re: bug#69993: Wrap window buffers while cycling
In-Reply-To: <867ch09bx6.fsf@HIDDEN> (Juri Linkov's message of "Sun,
14 Apr 2024 19:15:17 +0300")
Organization: LINKOV.NET
References: <86h6gug41x.fsf@HIDDEN>
<0d2fdebf-2149-4f92-89b8-45a8b6a7d272@HIDDEN>
<86plv8hz2v.fsf@HIDDEN>
<8a131d8b-1330-4d82-92f6-309f499e9c15@HIDDEN>
<86h6gi49zw.fsf@HIDDEN>
<1e50bd70-8cbb-46f9-9078-dd0e6226da63@HIDDEN>
<861q7k8gms.fsf@HIDDEN>
<2d3f0d14-e39b-4399-be30-03f11725c505@HIDDEN>
<86ttkf6a8r.fsf@HIDDEN> <86jzlajpqq.fsf@HIDDEN>
<85109880-3370-47e0-b7c9-6c5a32cfaafa@HIDDEN>
<86le5nhwqy.fsf@HIDDEN>
<f0a8c8ef-b722-4b62-ae17-c73cbef390ce@HIDDEN>
<864jcajzxi.fsf@HIDDEN>
<d8eea6ad-598d-4c77-8ddb-f8ab52f804bb@HIDDEN>
<86o7ahglre.fsf@HIDDEN>
<28a8149b-283a-4b08-9df5-f1139a0fccbe@HIDDEN>
<86ttk7m7ir.fsf@HIDDEN>
<1b38c78c-6697-4c6b-81cf-5a72fdd3ba8d@HIDDEN>
<868r1i8si0.fsf@HIDDEN> <867ch09bx6.fsf@HIDDEN>
Date: Tue, 16 Apr 2024 09:38:14 +0300
Message-ID: <867cgxn7lx.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/30.0.50 (x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain
X-GND-Sasl: juri@HIDDEN
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 69993
Cc: 69993 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)
>>>> So keeping the stable order of window prev/next buffers after C-x b
>>>> with a hook should be implemented in tab-line.el, not in window.el?
>>>
>>> I don't know how you currently handle C-x <left>, C-x b or
>>> 'rename-buffer' or whether a buffer is modified on the tab line so I
>>> can't tell whether you would need a hook for these. But this issue is
>>> IMHO not connected to whether getting the previous or next buffer should
>>> wrap or be restricted to buffers previously shown in a window.
>>
>> Handling 'C-x b' and 'rename-buffer' is not yet implemented.
>> Probably need to add a new window parameter to keep a list
>> of tab buffers and sync it with window prev/next buffers.
>
> Now handling 'C-x b' is completely implemented here:
>
> + (set-window-prev-buffers
> ...
> + (add-hook 'window-buffer-change-functions #'tab-line-buffer-change nil t)
Actually using hooks as well as advices in core packages is not a nice
thing to do. Neither tab-bar.el nor tab-line.el uses hooks and advices.
Also better not to mess with set-window-prev-buffers. And this is
perfectly possible with the following small patch that supports
everything: wrapping, C-x <left>, C-x b, 'rename-buffer' with
buffers restricted to those that were displayed in the window
while keeping them in the fixed order:
diff --git a/lisp/tab-line.el b/lisp/tab-line.el
index 54e9ee16243..b2f0cbf13ed 100644
--- a/lisp/tab-line.el
+++ b/lisp/tab-line.el
@@ -345,6 +345,8 @@ tab-line-tabs-function
grouped by `tab-line-tabs-buffer-group-function'."
:type '(choice (const :tag "Window buffers"
tab-line-tabs-window-buffers)
+ (const :tag "Window buffers with fixed order"
+ tab-line-tabs-fixed-window-buffers)
(const :tag "Same mode buffers"
tab-line-tabs-mode-buffers)
(const :tag "Grouped buffers"
@@ -515,6 +524,17 @@ tab-line-tabs-window-buffers
(list buffer)
next-buffers)))
+(defun tab-line-tabs-fixed-window-buffers ()
+ "Like `tab-line-tabs-window-buffers' but keep stable sorting order."
+ (let ((old-buffers (window-parameter nil 'tab-line-fixed-window-buffers))
+ (new-buffers (tab-line-tabs-window-buffers)))
+ (setq new-buffers (sort new-buffers
+ (lambda (a b)
+ (> (length (memq a old-buffers))
+ (length (memq b old-buffers))))))
+ (set-window-parameter nil 'tab-line-fixed-window-buffers new-buffers)
+ new-buffers))
bug-gnu-emacs@HIDDEN:bug#69993; Package emacs.
Full text available.
Received: (at 69993) by debbugs.gnu.org; 14 Apr 2024 16:18:00 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Apr 14 12:17:59 2024
Received: from localhost ([127.0.0.1]:36014 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1rw2YH-0007YX-KQ
for submit <at> debbugs.gnu.org; Sun, 14 Apr 2024 12:17:59 -0400
Received: from relay5-d.mail.gandi.net ([217.70.183.197]:51737)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <juri@HIDDEN>) id 1rw2Xw-0007Tb-US
for 69993 <at> debbugs.gnu.org; Sun, 14 Apr 2024 12:17:41 -0400
Received: by mail.gandi.net (Postfix) with ESMTPSA id E8CF11C0002;
Sun, 14 Apr 2024 16:17:18 +0000 (UTC)
From: Juri Linkov <juri@HIDDEN>
To: martin rudalics <rudalics@HIDDEN>
Subject: Re: bug#69993: Wrap window buffers while cycling
In-Reply-To: <868r1i8si0.fsf@HIDDEN> (Juri Linkov's message of "Fri,
12 Apr 2024 19:23:59 +0300")
Organization: LINKOV.NET
References: <86h6gug41x.fsf@HIDDEN> <86v850jmmo.fsf@HIDDEN>
<0d2fdebf-2149-4f92-89b8-45a8b6a7d272@HIDDEN>
<86plv8hz2v.fsf@HIDDEN>
<8a131d8b-1330-4d82-92f6-309f499e9c15@HIDDEN>
<86h6gi49zw.fsf@HIDDEN>
<1e50bd70-8cbb-46f9-9078-dd0e6226da63@HIDDEN>
<861q7k8gms.fsf@HIDDEN>
<2d3f0d14-e39b-4399-be30-03f11725c505@HIDDEN>
<86ttkf6a8r.fsf@HIDDEN> <86jzlajpqq.fsf@HIDDEN>
<85109880-3370-47e0-b7c9-6c5a32cfaafa@HIDDEN>
<86le5nhwqy.fsf@HIDDEN>
<f0a8c8ef-b722-4b62-ae17-c73cbef390ce@HIDDEN>
<864jcajzxi.fsf@HIDDEN>
<d8eea6ad-598d-4c77-8ddb-f8ab52f804bb@HIDDEN>
<86o7ahglre.fsf@HIDDEN>
<28a8149b-283a-4b08-9df5-f1139a0fccbe@HIDDEN>
<86ttk7m7ir.fsf@HIDDEN>
<1b38c78c-6697-4c6b-81cf-5a72fdd3ba8d@HIDDEN>
<868r1i8si0.fsf@HIDDEN>
Date: Sun, 14 Apr 2024 19:15:17 +0300
Message-ID: <867ch09bx6.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/30.0.50 (x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
X-GND-Sasl: juri@HIDDEN
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 69993
Cc: 69993 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)
--=-=-=
Content-Type: text/plain
>>> So keeping the stable order of window prev/next buffers after C-x b
>>> with a hook should be implemented in tab-line.el, not in window.el?
>>
>> I don't know how you currently handle C-x <left>, C-x b or
>> 'rename-buffer' or whether a buffer is modified on the tab line so I
>> can't tell whether you would need a hook for these. But this issue is
>> IMHO not connected to whether getting the previous or next buffer should
>> wrap or be restricted to buffers previously shown in a window.
>
> Handling 'C-x b' and 'rename-buffer' is not yet implemented.
> Probably need to add a new window parameter to keep a list
> of tab buffers and sync it with window prev/next buffers.
Now handling 'C-x b' is completely implemented here:
--=-=-=
Content-Type: text/x-diff
Content-Disposition: inline; filename=tab-line-buffer-change.patch
diff --git a/lisp/tab-line.el b/lisp/tab-line.el
index 54e9ee16243..776d33de3e2 100644
--- a/lisp/tab-line.el
+++ b/lisp/tab-line.el
@@ -843,26 +857,9 @@ tab-line-select-tab
(force-mode-line-update))))))))
(defun tab-line-select-tab-buffer (buffer &optional window)
- (let* ((window-buffer (window-buffer window))
- (next-buffers (seq-remove (lambda (b) (eq b window-buffer))
- (window-next-buffers window)))
- (prev-buffers (seq-remove (lambda (b) (eq b window-buffer))
- (mapcar #'car (window-prev-buffers window))))
- ;; Remove next-buffers from prev-buffers
- (prev-buffers (seq-difference prev-buffers next-buffers)))
- (cond
- ((and (eq tab-line-tabs-function #'tab-line-tabs-window-buffers)
- (memq buffer next-buffers))
- (dotimes (_ (1+ (seq-position next-buffers buffer)))
- (switch-to-next-buffer window)))
- ((and (eq tab-line-tabs-function #'tab-line-tabs-window-buffers)
- (memq buffer prev-buffers))
- (dotimes (_ (1+ (seq-position prev-buffers buffer)))
- (switch-to-prev-buffer window)))
- (t
- (with-selected-window window
- (let ((switch-to-buffer-obey-display-actions nil))
- (switch-to-buffer buffer)))))))
+ (with-selected-window window
+ (let ((switch-to-buffer-obey-display-actions nil))
+ (switch-to-buffer buffer))))
(defcustom tab-line-switch-cycling nil
"Enable cycling tab switch.
@@ -919,6 +916,26 @@ tab-line-switch-to-next-tab
(let ((switch-to-buffer-obey-display-actions nil))
(switch-to-buffer buffer))))))))
+(defun tab-line-buffer-change (_window)
+ (let* ((new-buffer (window-buffer))
+ (old-buffers (window-parameter nil 'tab-line-window-buffers))
+ (prev-buffers (window-prev-buffers))
+ (next-buffers (memq new-buffer old-buffers)))
+ (when next-buffers
+ (set-window-next-buffers nil (seq-filter (lambda (b)
+ (assq b prev-buffers))
+ (cdr next-buffers))))
+ (set-window-prev-buffers
+ nil (sort prev-buffers
+ (lambda (a b)
+ (cond
+ ((eq (car a) new-buffer) nil)
+ ((eq (car b) new-buffer) t)
+ (t (< (length (memq (car a) old-buffers))
+ (length (memq (car b) old-buffers))))))))
+ (set-window-parameter nil 'tab-line-window-buffers
+ (tab-line-tabs-window-buffers))))
+
(defcustom tab-line-close-tab-function 'bury-buffer
"What to do upon closing a tab on the tab line.
@@ -1025,13 +1042,17 @@ tab-line-mode
"Toggle display of tab line in the windows displaying the current buffer."
:lighter nil
(let ((default-value '(:eval (tab-line-format))))
- (if tab-line-mode
- ;; Preserve the existing tab-line set outside of this mode
- (unless tab-line-format
- (setq tab-line-format default-value))
+ (cond
+ (tab-line-mode
+ (add-hook 'window-buffer-change-functions #'tab-line-buffer-change nil t)
+ ;; Preserve the existing tab-line set outside of this mode
+ (unless tab-line-format
+ (setq tab-line-format default-value)))
+ (t
+ (remove-hook 'window-buffer-change-functions #'tab-line-buffer-change t)
;; Reset only values set by this mode
(when (equal tab-line-format default-value)
- (setq tab-line-format nil)))))
+ (setq tab-line-format nil))))))
(defcustom tab-line-exclude-modes
'(completion-list-mode)
--=-=-=--
bug-gnu-emacs@HIDDEN:bug#69993; Package emacs.
Full text available.Received: (at 69993) by debbugs.gnu.org; 12 Apr 2024 16:32:01 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Apr 12 12:32:01 2024 Received: from localhost ([127.0.0.1]:59495 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1rvJom-0004lU-E4 for submit <at> debbugs.gnu.org; Fri, 12 Apr 2024 12:32:01 -0400 Received: from relay9-d.mail.gandi.net ([2001:4b98:dc4:8::229]:49265) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <juri@HIDDEN>) id 1rvJoi-0004jv-EI for 69993 <at> debbugs.gnu.org; Fri, 12 Apr 2024 12:31:57 -0400 Received: by mail.gandi.net (Postfix) with ESMTPSA id 15B41FF803; Fri, 12 Apr 2024 16:31:37 +0000 (UTC) From: Juri Linkov <juri@HIDDEN> To: martin rudalics <rudalics@HIDDEN> Subject: Re: bug#69993: Wrap window buffers while cycling In-Reply-To: <1b38c78c-6697-4c6b-81cf-5a72fdd3ba8d@HIDDEN> (martin rudalics's message of "Fri, 12 Apr 2024 10:37:09 +0200") Organization: LINKOV.NET References: <86h6gug41x.fsf@HIDDEN> <efd1b8d1-cec3-4e18-8aba-7fc2db9edaba@HIDDEN> <86v850jmmo.fsf@HIDDEN> <0d2fdebf-2149-4f92-89b8-45a8b6a7d272@HIDDEN> <86plv8hz2v.fsf@HIDDEN> <8a131d8b-1330-4d82-92f6-309f499e9c15@HIDDEN> <86h6gi49zw.fsf@HIDDEN> <1e50bd70-8cbb-46f9-9078-dd0e6226da63@HIDDEN> <861q7k8gms.fsf@HIDDEN> <2d3f0d14-e39b-4399-be30-03f11725c505@HIDDEN> <86ttkf6a8r.fsf@HIDDEN> <86jzlajpqq.fsf@HIDDEN> <85109880-3370-47e0-b7c9-6c5a32cfaafa@HIDDEN> <86le5nhwqy.fsf@HIDDEN> <f0a8c8ef-b722-4b62-ae17-c73cbef390ce@HIDDEN> <864jcajzxi.fsf@HIDDEN> <d8eea6ad-598d-4c77-8ddb-f8ab52f804bb@HIDDEN> <86o7ahglre.fsf@HIDDEN> <28a8149b-283a-4b08-9df5-f1139a0fccbe@HIDDEN> <86ttk7m7ir.fsf@HIDDEN> <1b38c78c-6697-4c6b-81cf-5a72fdd3ba8d@HIDDEN> Date: Fri, 12 Apr 2024 19:23:59 +0300 Message-ID: <868r1i8si0.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/30.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-GND-Sasl: juri@HIDDEN X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 69993 Cc: 69993 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.7 (-) >>> But this would mean to change the ordering of elements on the tab line >>> whenever C-x b switches to a buffer already present on the tab line. >> >> Indeed, some hook is needed to restore the previous order after C-x b. >> Maybe 'window-buffer-change-functions' like you suggested. > > And I think that in such case 'tab-line-switch-to-prev-tab' and > 'switch-to-prev-buffer' should simply show different buffers. That is, > 'tab-line-switch-to-prev-tab' should _not_ use 'window-prev-buffers' to > get the buffer to switch to but simply use the buffer represented by the > tab visually preceding the current one on the tab line (stopping or > using the last one on the tab line if there is no preceding one). 'C-x <left>/<right>' is too nice keybinding to lose ;-) Therefore attempting to use it for navigating tab buffers. >> So keeping the stable order of window prev/next buffers after C-x b >> with a hook should be implemented in tab-line.el, not in window.el? > > I don't know how you currently handle C-x <left>, C-x b or > 'rename-buffer' or whether a buffer is modified on the tab line so I > can't tell whether you would need a hook for these. But this issue is > IMHO not connected to whether getting the previous or next buffer should > wrap or be restricted to buffers previously shown in a window. Handling 'C-x b' and 'rename-buffer' is not yet implemented. Probably need to add a new window parameter to keep a list of tab buffers and sync it with window prev/next buffers.
bug-gnu-emacs@HIDDEN:bug#69993; Package emacs.
Full text available.
Received: (at 69993) by debbugs.gnu.org; 12 Apr 2024 08:37:29 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Apr 12 04:37:29 2024
Received: from localhost ([127.0.0.1]:57846 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1rvCPZ-0002is-6S
for submit <at> debbugs.gnu.org; Fri, 12 Apr 2024 04:37:29 -0400
Received: from mout.gmx.net ([212.227.15.19]:44429)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <rudalics@HIDDEN>) id 1rvCPW-0002hJ-AA
for 69993 <at> debbugs.gnu.org; Fri, 12 Apr 2024 04:37:27 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.at;
s=s31663417; t=1712911030; x=1713515830; i=rudalics@HIDDEN;
bh=n64aA9lDtCShhU3hVoMjAoO6Uarxzhh/cMe2qKaZP+Q=;
h=X-UI-Sender-Class:Date:Subject:To:Cc:References:From:
In-Reply-To;
b=chhDzJ3DtAjegVtsOLHyghuP6rq0Nn+byXPCc4tTAQPLZEalMNo+VAsuPuu9N7eu
kdVGFffnYa1ON0VrxUf+JuVQEHhosNRs7+DFDHH3Xx/EDvjGvhm38nf80fMvb7tJz
f2NMIjqTHv6Ev/OjF2dpa+Ks1Q8bZviT5u20+BSAvEubOXoc+/SQ5iKNHlwTn2aX8
X0hwvldVgG6qB2oFdtCJtydMev96Jr8FYEgayFoPsRxuBS/EDcOgd0b+KjbRIcB6X
SmPs3tT6fIwVTdfXgmHHszcgYsAnHqsBItZ4GkuuOJc+sjLYvpF7mpoauOHFF6jDt
A6SkXl5SxkE0CC2Dxg==
X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a
Received: from [192.168.31.113] ([213.142.96.204]) by mail.gmx.net (mrgmx005
[212.227.17.190]) with ESMTPSA (Nemesis) id 1MOiDd-1s837h00UR-00QC3T; Fri, 12
Apr 2024 10:37:10 +0200
Message-ID: <1b38c78c-6697-4c6b-81cf-5a72fdd3ba8d@HIDDEN>
Date: Fri, 12 Apr 2024 10:37:09 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: bug#69993: Wrap window buffers while cycling
To: Juri Linkov <juri@HIDDEN>
References: <86h6gug41x.fsf@HIDDEN>
<91327e7b-d0a5-4f3a-a1f8-218d118608d6@HIDDEN>
<86sf07bnl4.fsf@HIDDEN>
<efd1b8d1-cec3-4e18-8aba-7fc2db9edaba@HIDDEN>
<86v850jmmo.fsf@HIDDEN>
<0d2fdebf-2149-4f92-89b8-45a8b6a7d272@HIDDEN>
<86plv8hz2v.fsf@HIDDEN>
<8a131d8b-1330-4d82-92f6-309f499e9c15@HIDDEN>
<86h6gi49zw.fsf@HIDDEN>
<1e50bd70-8cbb-46f9-9078-dd0e6226da63@HIDDEN>
<861q7k8gms.fsf@HIDDEN>
<2d3f0d14-e39b-4399-be30-03f11725c505@HIDDEN>
<86ttkf6a8r.fsf@HIDDEN> <86jzlajpqq.fsf@HIDDEN>
<85109880-3370-47e0-b7c9-6c5a32cfaafa@HIDDEN>
<86le5nhwqy.fsf@HIDDEN>
<f0a8c8ef-b722-4b62-ae17-c73cbef390ce@HIDDEN>
<864jcajzxi.fsf@HIDDEN>
<d8eea6ad-598d-4c77-8ddb-f8ab52f804bb@HIDDEN>
<86o7ahglre.fsf@HIDDEN>
<28a8149b-283a-4b08-9df5-f1139a0fccbe@HIDDEN>
<86ttk7m7ir.fsf@HIDDEN>
Content-Language: en-US
From: martin rudalics <rudalics@HIDDEN>
In-Reply-To: <86ttk7m7ir.fsf@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K1:dEwBjjYw2A5AR6f9trdbRDM1FOfFCuFJsGwBoVHXoYMAs0EFDZD
qoLXRNssHXL7Zkm3iOHKXDO5Ec4N2W85BnNLhxD93Rju8F0XDho8WPbmUwAfrdkNr720cN7
POddahj/UDtL7R5sArjv8u1/IFH2gp4gvZSgrSQsbYA34UyV6OLdKRC8nhDKkbdETRpnC3+
ZgB22gwKjQNRufq95OFRw==
X-Spam-Flag: NO
UI-OutboundReport: notjunk:1;M01:P0:RCZYKMAcxXo=;HOZtIt2fma9d8MCDAWfEt/tAs+g
VqM3A5MLytN8SPOZGhlnxINjYYt8qS9/RLdo4G69J8+EjW3Zt4xSSUmGvaIhA6DsuWENz2Jv4
sUio84hm8NipKwFU73X1SnM2eEq1xvEK3OCq7CzbHpflPM3HYH6CC+Kfm1qxfKD1VsTFdgHdB
dBC32mbIlrix9UhAbilc9H0PlLPcCb6RMmxTvs9o2EK538HVCfPk/TA4O5gXOmLaCoXNpqenn
Z1qLmQBHj9lUjGxhd2oFuOjZcBflv7kDOtzAMphvnF3Skqrw34+JQsEtL2P31ygZbNGPAD25q
ndHdh0omv3HNBQ4v8IO8bgB/oiyA0bvb+K/pR1gEmg91Dlsk9fIbFbJtt0ftpyxGSDmrOhnt+
nHmmqjUk252R2fTl/ywklHbht4vj78Ynhcmd6bncbk2HVxYF0JUtKYy9+ws9ESBYFBAn7Hb8j
tJAZP5eymHXwEyRIviRkOqyNk1huyh/99Nwpvf6hjJI1Pc/6phPR1SiklYnX32pukbg4Vn45d
ca1ihb8qH5xMA5eUm5C/qut+aaH8RTnrcnC6mdOLzGm6BbeLgsLRZ+w/82evEpjDPmNEmQskH
TvA8bUCA2/R8uXwtbCjQrW8+jyE0QYYqz7o7m27XABHu8cC6VFd7sp0lFYpl28o+xILvt91Oj
yOtRtL3qW69GdNmuLnmRNqnQ8RvBkaqvyJLIrTlfZhDAHw2uRlXflEZE/dTalFC2zSpIq/dkw
CKa6CYirrS5xfiAuPJKGlA3skq7GDqYK/47Nsa1PJ/QSu6V69qGwQZ8F5Fp/y1Ouvghfg3pD1
L3Rl77VnBsPEO8/pqfFyjCEAcfDy1BwerT5g4MCdu73/LlsIkhunL5w6YY37lYRhv4
X-Spam-Score: 2.9 (++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
has NOT identified this incoming email as spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
the administrator of that system for details.
Content preview: >> But this would mean to change the ordering of elements
on the tab line >> whenever C-x b switches to a buffer already present on
the tab line. > > Indeed, some hook is needed to restore the previo [...]
Content analysis details: (2.9 points, 10.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
3.6 RCVD_IN_SBL_CSS RBL: Received via a relay in Spamhaus SBL-CSS
[213.142.96.204 listed in zen.spamhaus.org]
-0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at https://www.dnswl.org/,
low trust [212.227.15.19 listed in list.dnswl.org]
-0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2)
[212.227.15.19 listed in wl.mailspike.net]
-0.0 SPF_PASS SPF: sender matches SPF record
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail
provider (rudalics[at]gmx.at)
0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record
X-Debbugs-Envelope-To: 69993
Cc: 69993 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 1.9 (+)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
has NOT identified this incoming email as spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
the administrator of that system for details.
Content preview: >> But this would mean to change the ordering of elements
on the tab line >> whenever C-x b switches to a buffer already present on
the tab line. > > Indeed, some hook is needed to restore the previo [...]
Content analysis details: (1.9 points, 10.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
-0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at https://www.dnswl.org/,
low trust
[212.227.15.19 listed in list.dnswl.org]
3.6 RCVD_IN_SBL_CSS RBL: Received via a relay in Spamhaus SBL-CSS
[213.142.96.204 listed in zen.spamhaus.org]
-0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2)
[212.227.15.19 listed in wl.mailspike.net]
-0.0 SPF_PASS SPF: sender matches SPF record
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail
provider (rudalics[at]gmx.at)
0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record
-1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list
manager
>> But this would mean to change the ordering of elements on the tab line
>> whenever C-x b switches to a buffer already present on the tab line.
>
> Indeed, some hook is needed to restore the previous order after C-x b.
> Maybe 'window-buffer-change-functions' like you suggested.
And I think that in such case 'tab-line-switch-to-prev-tab' and
'switch-to-prev-buffer' should simply show different buffers. That is,
'tab-line-switch-to-prev-tab' should _not_ use 'window-prev-buffers' to
get the buffer to switch to but simply use the buffer represented by the
tab visually preceding the current one on the tab line (stopping or
using the last one on the tab line if there is no preceding one).
> So keeping the stable order of window prev/next buffers after C-x b
> with a hook should be implemented in tab-line.el, not in window.el?
I don't know how you currently handle C-x <left>, C-x b or
'rename-buffer' or whether a buffer is modified on the tab line so I
can't tell whether you would need a hook for these. But this issue is
IMHO not connected to whether getting the previous or next buffer should
wrap or be restricted to buffers previously shown in a window.
martin
bug-gnu-emacs@HIDDEN:bug#69993; Package emacs.
Full text available.Received: (at 69993) by debbugs.gnu.org; 12 Apr 2024 06:49:41 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Apr 12 02:49:40 2024 Received: from localhost ([127.0.0.1]:57741 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1rvAjC-0006u2-G2 for submit <at> debbugs.gnu.org; Fri, 12 Apr 2024 02:49:40 -0400 Received: from relay3-d.mail.gandi.net ([2001:4b98:dc4:8::223]:43991) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <juri@HIDDEN>) id 1rvAj8-0006rt-CW for 69993 <at> debbugs.gnu.org; Fri, 12 Apr 2024 02:49:35 -0400 Received: by mail.gandi.net (Postfix) with ESMTPSA id 6D8CB60007; Fri, 12 Apr 2024 06:49:18 +0000 (UTC) From: Juri Linkov <juri@HIDDEN> To: martin rudalics <rudalics@HIDDEN> Subject: Re: bug#69993: Wrap window buffers while cycling In-Reply-To: <28a8149b-283a-4b08-9df5-f1139a0fccbe@HIDDEN> (martin rudalics's message of "Thu, 11 Apr 2024 11:18:12 +0200") Organization: LINKOV.NET References: <86h6gug41x.fsf@HIDDEN> <91327e7b-d0a5-4f3a-a1f8-218d118608d6@HIDDEN> <86sf07bnl4.fsf@HIDDEN> <efd1b8d1-cec3-4e18-8aba-7fc2db9edaba@HIDDEN> <86v850jmmo.fsf@HIDDEN> <0d2fdebf-2149-4f92-89b8-45a8b6a7d272@HIDDEN> <86plv8hz2v.fsf@HIDDEN> <8a131d8b-1330-4d82-92f6-309f499e9c15@HIDDEN> <86h6gi49zw.fsf@HIDDEN> <1e50bd70-8cbb-46f9-9078-dd0e6226da63@HIDDEN> <861q7k8gms.fsf@HIDDEN> <2d3f0d14-e39b-4399-be30-03f11725c505@HIDDEN> <86ttkf6a8r.fsf@HIDDEN> <86jzlajpqq.fsf@HIDDEN> <85109880-3370-47e0-b7c9-6c5a32cfaafa@HIDDEN> <86le5nhwqy.fsf@HIDDEN> <f0a8c8ef-b722-4b62-ae17-c73cbef390ce@HIDDEN> <864jcajzxi.fsf@HIDDEN> <d8eea6ad-598d-4c77-8ddb-f8ab52f804bb@HIDDEN> <86o7ahglre.fsf@HIDDEN> <28a8149b-283a-4b08-9df5-f1139a0fccbe@HIDDEN> Date: Fri, 12 Apr 2024 09:35:08 +0300 Message-ID: <86ttk7m7ir.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/30.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-GND-Sasl: juri@HIDDEN X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 69993 Cc: 69993 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.7 (-) >> 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. > > But this would mean to change the ordering of elements on the tab line > whenever C-x b switches to a buffer already present on the tab line. Indeed, some hook is needed to restore the previous order after C-x b. Maybe 'window-buffer-change-functions' like you suggested. >>> 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. > > IIUC it isn't, given the C-x b example. So keeping the stable order of window prev/next buffers after C-x b with a hook should be implemented in tab-line.el, not in window.el?
bug-gnu-emacs@HIDDEN:bug#69993; Package emacs.
Full text available.
Received: (at 69993) by debbugs.gnu.org; 11 Apr 2024 09:18:33 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Apr 11 05:18:33 2024
Received: from localhost ([127.0.0.1]:54948 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1ruqZk-0000nP-GP
for submit <at> debbugs.gnu.org; Thu, 11 Apr 2024 05:18:33 -0400
Received: from mout.gmx.net ([212.227.17.20]:54645)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <rudalics@HIDDEN>) id 1ruqZi-0000mU-DT
for 69993 <at> debbugs.gnu.org; Thu, 11 Apr 2024 05:18:31 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.at;
s=s31663417; t=1712827095; x=1713431895; i=rudalics@HIDDEN;
bh=7ynXX73L+GQ8r9wJgpjM5pFrgKB9ALD31UMaa75ZJVA=;
h=X-UI-Sender-Class:Message-ID:Date:MIME-Version:Subject:To:Cc:
References:From:In-Reply-To:Content-Type:
Content-Transfer-Encoding:cc:content-transfer-encoding:
content-type:date:from:message-id:mime-version:reply-to:subject:
to;
b=UJgJETKNY5XQlIovfcwHzYlXWA3881gtK6glcXJgOH0GQRwXFhlFKmhH7uEY9IeP
bd1CKUz49wm4Ze8q8wAREI5JbsSMm8+9V/+C/RqB/yN8n5YLxYi0I8KkaZTHObw5E
ucWaHBfhHzSbgRMhjc24595j0RLImJEkV5A/6HzKG3cOnEPcjsyNLNQPFDhW5l70E
rFDSycdhmiDKfaHNtun+pRlkyGUnQV96zYatm0HdgOt2EpwQkfMJcR56kn1tnQo2S
2XlhNcGXNtyOu0nRzjk3GBTeKakHjtG87HotSJRpItTiWQWbLfYeC1w+FCaY4nutu
deS4F7tfncZ9s6reUA==
X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a
Received: from [192.168.31.113] ([213.142.96.248]) by mail.gmx.net (mrgmx105
[212.227.17.168]) with ESMTPSA (Nemesis) id 1MeCpb-1sRz851i7j-00bKLi; Thu, 11
Apr 2024 11:18:15 +0200
Message-ID: <28a8149b-283a-4b08-9df5-f1139a0fccbe@HIDDEN>
Date: Thu, 11 Apr 2024 11:18:12 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: bug#69993: Wrap window buffers while cycling
To: Juri Linkov <juri@HIDDEN>
References: <86h6gug41x.fsf@HIDDEN>
<f3c9969f-64a0-491b-a5a8-7417a2cb9d45@HIDDEN>
<86v855ggkv.fsf@HIDDEN>
<91327e7b-d0a5-4f3a-a1f8-218d118608d6@HIDDEN>
<86sf07bnl4.fsf@HIDDEN>
<efd1b8d1-cec3-4e18-8aba-7fc2db9edaba@HIDDEN>
<86v850jmmo.fsf@HIDDEN>
<0d2fdebf-2149-4f92-89b8-45a8b6a7d272@HIDDEN>
<86plv8hz2v.fsf@HIDDEN>
<8a131d8b-1330-4d82-92f6-309f499e9c15@HIDDEN>
<86h6gi49zw.fsf@HIDDEN>
<1e50bd70-8cbb-46f9-9078-dd0e6226da63@HIDDEN>
<861q7k8gms.fsf@HIDDEN>
<2d3f0d14-e39b-4399-be30-03f11725c505@HIDDEN>
<86ttkf6a8r.fsf@HIDDEN> <86jzlajpqq.fsf@HIDDEN>
<85109880-3370-47e0-b7c9-6c5a32cfaafa@HIDDEN>
<86le5nhwqy.fsf@HIDDEN>
<f0a8c8ef-b722-4b62-ae17-c73cbef390ce@HIDDEN>
<864jcajzxi.fsf@HIDDEN>
<d8eea6ad-598d-4c77-8ddb-f8ab52f804bb@HIDDEN>
<86o7ahglre.fsf@HIDDEN>
Content-Language: en-US
From: martin rudalics <rudalics@HIDDEN>
In-Reply-To: <86o7ahglre.fsf@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K1:qbt6hlmEx9zUt/8lVBM89cXU0ng7kSVVxV0Jv7V6MqG8ryxLhZc
t7ZXS1ipnGweOH5QWUJb3meySI3LVU4C/dIgkJGgjv5cSj0Hy9SeoxcQSm96O5kBxGaCZDZ
u3pP8TSJ0mVFoKldL7oz3ZiVwXnscjKJ4jgxMm9qkGPp7iASP5i/fCdeBybymwVmIsNa7BP
Hqs1LEQbxur/wbYZMyi1w==
X-Spam-Flag: NO
UI-OutboundReport: notjunk:1;M01:P0:q7XONXziItE=;n1l1WUlRibuRr9klSNfXkzug5FN
03aCrwc8gQTRONbJBa0ammmICTP9AwIu241S7ClXxRhg7OFysQ15PyMm2FsFo7PgcDIZFqas9
8YgIZ6aIayIgxA+vJrvPGZwhwWHhO+QB3Z4dimSR5bA/JUc5HmvKJYCxjV4QmAE5GyOnQE3uK
li3m00y/ugEW/4GBZVADfkSU/V+oGX+QHGxqiaGqxEHahhp7insVpVE/sFmeR1WBKn+XulZxj
vLDFHB1ZiOL/BRdQKISqZnW2LJbShsWQ+9iUBOVZVVGxhndmSxSNamNE6xbTUb7+QOZnqeLPE
jOaJLxZya0W0HtelD9tGBbxthcTGceoJ5Du0y5i/wGffyDxXXyU5E0ZUNJ71Vo477GWr89zJz
0Fd/Cro7PZgSVSLmlvTgI0g9S+uQqpFfTNWTNoYxg/K2VrdlGx/pI5H28VqSSUhH4Us9qMV4K
CsNfV5W/O2d2aHRKMpwqEVd44roKUSR3pI0XJeZdP+Vgfv/t8xAfuDuq2w5sCr88I2LW16ZKc
uYgB9cWXXEpKP2NaGQAW6heYA5ZVSfb32TxNA3O8kZ/q1DQjGhp3jPLyCL1zI30GZxG34m8aq
Mz+sIP0NZsYNL+Ixsjtgy4OOlMCvRqY4xbMUr1OLXwl4MzsUFH7HsUFGmMQ8gn8WBRJujnG5I
NoIDyz6+uWdBPc9XgBL7gItJDWYc/dE0i66sIP8gTb8ME9v3jR6+5sBzgsevcHhNO5zfdxDIK
yM22vCPRh8rF8oX1fg5HDN6Uy6/IsqAhAyva2tPOz5Br5LQynpQ4C0TDUlLYg7qZrap9EwQ6V
BoHH9N1tGRBrCvgceiYnK+MvqhZ8XHOK7xFKJgt1NuHEIObJjO3W3c4DlpirunpXJq
X-Spam-Score: 2.9 (++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
has NOT identified this incoming email as spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
the administrator of that system for details.
Content preview: >> 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 select [...]
Content analysis details: (2.9 points, 10.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
-0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at https://www.dnswl.org/,
low trust [212.227.17.20 listed in list.dnswl.org]
3.6 RCVD_IN_SBL_CSS RBL: Received via a relay in Spamhaus SBL-CSS
[213.142.96.248 listed in zen.spamhaus.org]
-0.0 SPF_PASS SPF: sender matches SPF record
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail
provider (rudalics[at]gmx.at)
0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record
-0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2)
[212.227.17.20 listed in wl.mailspike.net]
X-Debbugs-Envelope-To: 69993
Cc: 69993 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 1.9 (+)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
has NOT identified this incoming email as spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
the administrator of that system for details.
Content preview: >> 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 select [...]
Content analysis details: (1.9 points, 10.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
-0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at https://www.dnswl.org/,
low trust
[212.227.17.20 listed in list.dnswl.org]
3.6 RCVD_IN_SBL_CSS RBL: Received via a relay in Spamhaus SBL-CSS
[213.142.96.248 listed in zen.spamhaus.org]
-0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2)
[212.227.17.20 listed in wl.mailspike.net]
-0.0 SPF_PASS SPF: sender matches SPF record
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail
provider (rudalics[at]gmx.at)
0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record
-1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list
manager
>> 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.
I meant 'switch-to-prev-buffer' which must be allowed to switch to the
previous buffer it finds and that could be _any_ buffer on the tab line
and, without "restricting", a buffer that is not even on the tab line.
>> 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.
I thought we agreed that it should do so with an appropriate binding.
> 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'.
Once it uses the binding it can either wrap or not. I see no problem
here.
> 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.
But this would mean to change the ordering of elements on the tab line
whenever C-x b switches to a buffer already present on the tab line.
>> 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.
IIUC it isn't, given the C-x b example.
martin
bug-gnu-emacs@HIDDEN:bug#69993; Package emacs.
Full text available.Received: (at 69993) by debbugs.gnu.org; 10 Apr 2024 18:03:15 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Apr 10 14:03:15 2024 Received: from localhost ([127.0.0.1]:54331 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1rucHy-0001hn-Va for submit <at> debbugs.gnu.org; Wed, 10 Apr 2024 14:03:15 -0400 Received: from relay5-d.mail.gandi.net ([217.70.183.197]:46861) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <juri@HIDDEN>) id 1rucHo-0001eX-1u for 69993 <at> debbugs.gnu.org; Wed, 10 Apr 2024 14:03:06 -0400 Received: by mail.gandi.net (Postfix) with ESMTPSA id E19451C0004; Wed, 10 Apr 2024 18:02:48 +0000 (UTC) From: Juri Linkov <juri@HIDDEN> To: martin rudalics <rudalics@HIDDEN> Subject: Re: bug#69993: Wrap window buffers while cycling In-Reply-To: <d8eea6ad-598d-4c77-8ddb-f8ab52f804bb@HIDDEN> (martin rudalics's message of "Wed, 10 Apr 2024 10:46:48 +0200") Organization: LINKOV.NET References: <86h6gug41x.fsf@HIDDEN> <f3c9969f-64a0-491b-a5a8-7417a2cb9d45@HIDDEN> <86v855ggkv.fsf@HIDDEN> <91327e7b-d0a5-4f3a-a1f8-218d118608d6@HIDDEN> <86sf07bnl4.fsf@HIDDEN> <efd1b8d1-cec3-4e18-8aba-7fc2db9edaba@HIDDEN> <86v850jmmo.fsf@HIDDEN> <0d2fdebf-2149-4f92-89b8-45a8b6a7d272@HIDDEN> <86plv8hz2v.fsf@HIDDEN> <8a131d8b-1330-4d82-92f6-309f499e9c15@HIDDEN> <86h6gi49zw.fsf@HIDDEN> <1e50bd70-8cbb-46f9-9078-dd0e6226da63@HIDDEN> <861q7k8gms.fsf@HIDDEN> <2d3f0d14-e39b-4399-be30-03f11725c505@HIDDEN> <86ttkf6a8r.fsf@HIDDEN> <86jzlajpqq.fsf@HIDDEN> <85109880-3370-47e0-b7c9-6c5a32cfaafa@HIDDEN> <86le5nhwqy.fsf@HIDDEN> <f0a8c8ef-b722-4b62-ae17-c73cbef390ce@HIDDEN> <864jcajzxi.fsf@HIDDEN> <d8eea6ad-598d-4c77-8ddb-f8ab52f804bb@HIDDEN> Date: Wed, 10 Apr 2024 20:45:30 +0300 Message-ID: <86o7ahglre.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/30.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-GND-Sasl: juri@HIDDEN X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 69993 Cc: 69993 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.7 (-) > 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.
bug-gnu-emacs@HIDDEN:bug#69993; Package emacs.
Full text available.
Received: (at 69993) by debbugs.gnu.org; 10 Apr 2024 08:47:09 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Apr 10 04:47:09 2024
Received: from localhost ([127.0.0.1]:52116 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1ruTbo-00011t-D0
for submit <at> debbugs.gnu.org; Wed, 10 Apr 2024 04:47:09 -0400
Received: from mout.gmx.net ([212.227.17.22]:59217)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <rudalics@HIDDEN>) id 1ruTbl-000101-2m
for 69993 <at> debbugs.gnu.org; Wed, 10 Apr 2024 04:47:07 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.at;
s=s31663417; t=1712738810; x=1713343610; i=rudalics@HIDDEN;
bh=GUo587MBqIu9oieDSJmp3TNKardhwYdljen9JmwjqJU=;
h=X-UI-Sender-Class:Date:Subject:To:Cc:References:From:
In-Reply-To;
b=JHoelr1S/Kk+7gbYhUqqnm+RzQ/Ki/fDglNnGPZlaPb5XeXwwC5vehYgr6HojzsX
xfYQBB8nM5s/6+NMZ2EERictjr83aYJoreOCfNi3hbRF3usabp3tIItDC38XV5umY
6OUQYERsC/8Kezh9Zh5w6ijPRUdN9V9Zw3cFfIpYNldMPrqtzPy0lD6HK0nM+/eOY
ra7+66BRnPKcQNodN8rKWEq5iCr6yzSAlHfXk3xbvxdZE3iM2Na1D5MJCgxCnF+kc
WPHO53Rka8QfQVbeqwoN17a1102FrDiakXjGTdswTHS4H10s1jITQVLfWa+YLUSiL
Ra7RMm4i7vTVguvbrg==
X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a
Received: from [192.168.31.113] ([46.125.249.84]) by mail.gmx.net (mrgmx105
[212.227.17.168]) with ESMTPSA (Nemesis) id 1N7QxB-1sr91A3Pe1-017mkp; Wed, 10
Apr 2024 10:46:49 +0200
Message-ID: <d8eea6ad-598d-4c77-8ddb-f8ab52f804bb@HIDDEN>
Date: Wed, 10 Apr 2024 10:46:48 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: bug#69993: Wrap window buffers while cycling
To: Juri Linkov <juri@HIDDEN>
References: <86h6gug41x.fsf@HIDDEN>
<463c9242-56ef-4c99-9fe6-4b70be2071b2@HIDDEN>
<86sf0abeg3.fsf@HIDDEN>
<f3c9969f-64a0-491b-a5a8-7417a2cb9d45@HIDDEN>
<86v855ggkv.fsf@HIDDEN>
<91327e7b-d0a5-4f3a-a1f8-218d118608d6@HIDDEN>
<86sf07bnl4.fsf@HIDDEN>
<efd1b8d1-cec3-4e18-8aba-7fc2db9edaba@HIDDEN>
<86v850jmmo.fsf@HIDDEN>
<0d2fdebf-2149-4f92-89b8-45a8b6a7d272@HIDDEN>
<86plv8hz2v.fsf@HIDDEN>
<8a131d8b-1330-4d82-92f6-309f499e9c15@HIDDEN>
<86h6gi49zw.fsf@HIDDEN>
<1e50bd70-8cbb-46f9-9078-dd0e6226da63@HIDDEN>
<861q7k8gms.fsf@HIDDEN>
<2d3f0d14-e39b-4399-be30-03f11725c505@HIDDEN>
<86ttkf6a8r.fsf@HIDDEN> <86jzlajpqq.fsf@HIDDEN>
<85109880-3370-47e0-b7c9-6c5a32cfaafa@HIDDEN>
<86le5nhwqy.fsf@HIDDEN>
<f0a8c8ef-b722-4b62-ae17-c73cbef390ce@HIDDEN>
<864jcajzxi.fsf@HIDDEN>
Content-Language: en-US
From: martin rudalics <rudalics@HIDDEN>
In-Reply-To: <864jcajzxi.fsf@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K1:ICMjCKlZVqQuJ0wDTeUYq/79ET7isFlXZw+CkmomnQRM9c9UaN7
r9zUuowDqL4/efzhAIol2c6ZVFgIZk0bV/cYR7R9QkT41x99oIPjzUJ25XLExL8c7n+PBch
ynRVDMR7LW0L4NtE9iM82JHd9BIe/UcVfRXoG1CstHRTVDwFOE8q6RdpZpYZm0IB7yY4mtp
YzXMJIJOgHBjlCawtZAFQ==
X-Spam-Flag: NO
UI-OutboundReport: notjunk:1;M01:P0:1BN/AmcHHJ8=;9PJjH0cvhvTvcGE/IfXQAwVp4X9
912TcAgIISjOLbNHY0SDD//8G+su2e1smRTmIE6otXQ0u4Kmbjm+xGvSgBp9iOwgDdhGcoR87
RNG4Z58eiUCn4PFge8kI1OuDfAFyioRDAiE3DD5AlYYNWbuN9WuBakz2PQK4rzXQa1tdWlXEf
83qAOeOdKQRxrRAjN3a2PHp5hqmDj/pjvNR5RYfc8ozihrmTpuSVUZWsutZXUj89RfgX+qpJL
a0BTrFYp+FIpqStZCoBcrFbGNzjQAF/4f8et9DnVVPZUNLwZNUAqp2F8OACNQ+oZd96CLpIrV
BeGFwXRAXtZtSxsqvZkbeE0njYZRIFxad+T55JNPzq2kpqd8ff9js8CS5LxWDowkd9JjBSsnx
WXLXpNqWFINU3Mrr4BSzwQ7Kti8TGc4r0PeaKFWhVT5JXKH0P+5jgVpJYwjm+f667j3M7gIxv
UdPL/9T0Ddkq8yNt+8VMF7C0D/2tQCyq8UTPvuAgSebzVJH+Z+2xG6reNIZInx5X7jdHzBZD9
sOvK6IHDv1ebJVkXv8s+2TUW6Ccb8jvKG2Wt3mnuzYMBJ1q5VA4Pv+SwLzuOqY23uWB4Fvsfg
S0p4rf+CaCSKZJOoVjY6PXKszgjkFjH0TSYB+XdP5bZqFeZb65uoSlqE/YOqkD05VgAkp8uQ1
VhiWrISSl1ccMMMxJzcQb8SbvzwBWkRsdGfJFFFYzddOqtmvzotS8vLfT3PJFe3h60RHDIYVl
tD/HfhEuR2sB4t8G36XUXzhl9CqGI482rBgqVeV/VdBVcM4t1YcqgNXeTsIjr5blxEhQaZ5Vc
h5vv3l6nt6D8woQa3XSW3dACF9O+O3RI9b9Yk0OnxargI=
X-Spam-Score: 4.4 (++++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
has NOT identified this incoming email as spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
the administrator of that system for details.
Content preview: >> 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-swit [...]
Content analysis details: (4.4 points, 10.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
3.6 RCVD_IN_SBL_CSS RBL: Received via a relay in Spamhaus SBL-CSS
[46.125.249.84 listed in zen.spamhaus.org]
1.5 RCVD_IN_SORBS_WEB RBL: SORBS: sender is an abusable web server
[46.125.249.84 listed in dnsbl.sorbs.net]
-0.0 SPF_PASS SPF: sender matches SPF record
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail
provider (rudalics[at]gmx.at)
0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record
-0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2)
[212.227.17.22 listed in wl.mailspike.net]
-0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at https://www.dnswl.org/,
low trust [212.227.17.22 listed in list.dnswl.org]
X-Debbugs-Envelope-To: 69993
Cc: 69993 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 3.4 (+++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
has NOT identified this incoming email as spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
the administrator of that system for details.
Content preview: >> 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-swit [...]
Content analysis details: (3.4 points, 10.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
-0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at https://www.dnswl.org/,
low trust
[212.227.17.22 listed in list.dnswl.org]
3.6 RCVD_IN_SBL_CSS RBL: Received via a relay in Spamhaus SBL-CSS
[46.125.249.84 listed in zen.spamhaus.org]
1.5 RCVD_IN_SORBS_WEB RBL: SORBS: sender is an abusable web server
[46.125.249.84 listed in dnsbl.sorbs.net]
-0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2)
[212.227.17.22 listed in wl.mailspike.net]
-0.0 SPF_PASS SPF: sender matches SPF record
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail
provider (rudalics[at]gmx.at)
0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record
-1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list
manager
>> 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.
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. 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. 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?
>> '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.
> 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.
martin
bug-gnu-emacs@HIDDEN:bug#69993; Package emacs.
Full text available.Received: (at 69993) by debbugs.gnu.org; 9 Apr 2024 16:47:36 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Apr 09 12:47:36 2024 Received: from localhost ([127.0.0.1]:51314 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1ruEdE-0000xm-9O for submit <at> debbugs.gnu.org; Tue, 09 Apr 2024 12:47:36 -0400 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 <juri@HIDDEN>) id 1ruEdB-0000wj-DY for 69993 <at> debbugs.gnu.org; Tue, 09 Apr 2024 12:47:33 -0400 Received: by mail.gandi.net (Postfix) with ESMTPSA id EE37C1BF206; Tue, 9 Apr 2024 16:47:17 +0000 (UTC) From: Juri Linkov <juri@HIDDEN> To: martin rudalics <rudalics@HIDDEN> Subject: Re: bug#69993: Wrap window buffers while cycling In-Reply-To: <f0a8c8ef-b722-4b62-ae17-c73cbef390ce@HIDDEN> (martin rudalics's message of "Tue, 9 Apr 2024 11:04:38 +0200") Organization: LINKOV.NET References: <86h6gug41x.fsf@HIDDEN> <463c9242-56ef-4c99-9fe6-4b70be2071b2@HIDDEN> <86sf0abeg3.fsf@HIDDEN> <f3c9969f-64a0-491b-a5a8-7417a2cb9d45@HIDDEN> <86v855ggkv.fsf@HIDDEN> <91327e7b-d0a5-4f3a-a1f8-218d118608d6@HIDDEN> <86sf07bnl4.fsf@HIDDEN> <efd1b8d1-cec3-4e18-8aba-7fc2db9edaba@HIDDEN> <86v850jmmo.fsf@HIDDEN> <0d2fdebf-2149-4f92-89b8-45a8b6a7d272@HIDDEN> <86plv8hz2v.fsf@HIDDEN> <8a131d8b-1330-4d82-92f6-309f499e9c15@HIDDEN> <86h6gi49zw.fsf@HIDDEN> <1e50bd70-8cbb-46f9-9078-dd0e6226da63@HIDDEN> <861q7k8gms.fsf@HIDDEN> <2d3f0d14-e39b-4399-be30-03f11725c505@HIDDEN> <86ttkf6a8r.fsf@HIDDEN> <86jzlajpqq.fsf@HIDDEN> <85109880-3370-47e0-b7c9-6c5a32cfaafa@HIDDEN> <86le5nhwqy.fsf@HIDDEN> <f0a8c8ef-b722-4b62-ae17-c73cbef390ce@HIDDEN> Date: Tue, 09 Apr 2024 19:37:50 +0300 Message-ID: <864jcajzxi.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/30.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-GND-Sasl: juri@HIDDEN X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 69993 Cc: 69993 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.7 (-) >> 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.
bug-gnu-emacs@HIDDEN:bug#69993; Package emacs.
Full text available.Received: (at 69993) by debbugs.gnu.org; 9 Apr 2024 09:04:56 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Apr 09 05:04:56 2024 Received: from localhost ([127.0.0.1]:48257 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1ru7PU-0001kX-CO for submit <at> debbugs.gnu.org; Tue, 09 Apr 2024 05:04:56 -0400 Received: from mout.gmx.net ([212.227.15.15]:33975) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <rudalics@HIDDEN>) id 1ru7PS-0001kK-EE for 69993 <at> debbugs.gnu.org; Tue, 09 Apr 2024 05:04:55 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.at; s=s31663417; t=1712653480; x=1713258280; i=rudalics@HIDDEN; bh=d8Uf3sVL5o4G+wqMwDKf5L4IU+CVlmw1V+O0b/fSb/8=; h=X-UI-Sender-Class:Date:Subject:To:Cc:References:From: In-Reply-To; b=j5sqas3MqP4x4r7CvFZi6Bezf4NgA0cLQpoPrH76oL1FVCtFoDxmHYkPTXv0p0IO 4UGFUZ0+vIyCOjUi4eyXhQBaCu8JV2H4giSxym7h4H951Gi3xR1RUTVnAvBQgWPCv Jn+G+DeUG1RXfZuazA5oW7mel5T/1XfoFvjUMDv3r+bz6mJvd93mdsbggjL7JNUfh BjryGyQxNbZ4j/xP7SMPMIq3mGfHhPpvPY00aSPCUHGqMjeRtA5Lc6cJE+fq7zQjl OMi8rMIv5wlwro2xRz1w1EozgFf41RMTPlerQwXGpvHoTT2kb1zu6VvAooVpAhW6n e96MYeh4E66AOO3cnA== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from [192.168.31.113] ([212.95.5.15]) by mail.gmx.net (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1Mr9Bk-1sXLu20n3u-00oC5L; Tue, 09 Apr 2024 11:04:40 +0200 Message-ID: <f0a8c8ef-b722-4b62-ae17-c73cbef390ce@HIDDEN> Date: Tue, 9 Apr 2024 11:04:38 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#69993: Wrap window buffers while cycling To: Juri Linkov <juri@HIDDEN> References: <86h6gug41x.fsf@HIDDEN> <5c71ea64-0f97-4b90-af61-1156fe33f1ea@HIDDEN> <86cyreu78w.fsf@HIDDEN> <463c9242-56ef-4c99-9fe6-4b70be2071b2@HIDDEN> <86sf0abeg3.fsf@HIDDEN> <f3c9969f-64a0-491b-a5a8-7417a2cb9d45@HIDDEN> <86v855ggkv.fsf@HIDDEN> <91327e7b-d0a5-4f3a-a1f8-218d118608d6@HIDDEN> <86sf07bnl4.fsf@HIDDEN> <efd1b8d1-cec3-4e18-8aba-7fc2db9edaba@HIDDEN> <86v850jmmo.fsf@HIDDEN> <0d2fdebf-2149-4f92-89b8-45a8b6a7d272@HIDDEN> <86plv8hz2v.fsf@HIDDEN> <8a131d8b-1330-4d82-92f6-309f499e9c15@HIDDEN> <86h6gi49zw.fsf@HIDDEN> <1e50bd70-8cbb-46f9-9078-dd0e6226da63@HIDDEN> <861q7k8gms.fsf@HIDDEN> <2d3f0d14-e39b-4399-be30-03f11725c505@HIDDEN> <86ttkf6a8r.fsf@HIDDEN> <86jzlajpqq.fsf@HIDDEN> <85109880-3370-47e0-b7c9-6c5a32cfaafa@HIDDEN> <86le5nhwqy.fsf@HIDDEN> Content-Language: en-US From: martin rudalics <rudalics@HIDDEN> In-Reply-To: <86le5nhwqy.fsf@HIDDEN> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:6ZupmI5fILsvTwxVXlVe+MsA1sI79ZANShQE3I+uCYYGzOyGBMZ 2xEU+vU0tlg1TpmfBX+BahOLbfAOX2WSV+u9Tg2YxvG5IPZAFO86RbEyrWHdObSq1MWJtp5 F4Tqkw5z+Qx//PwCHUGg+O4e5sY8xh0JSInuhXsRKclKWZiBb0Fq2tDmGnDdwA9t6P9VHPu L8mA0HNJ+TyWfKo1iGH0Q== X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:8pcBL9GLJMk=;QJlGyzPgR8JLNJdYPk/jxVVX0QN DK6sZ2NSuZ81doro+TPj+xvZ24tdQfRA7mDfvNqusxhTgZoiNmRDMEp4eZbgbAejpTXTQwsoy gUzLuwmps83P12MI7bUofy6FYA5AfEdCBar5pu0GAobvkaislxCqRDsiQ8Q/WnPWk/CkmEAGO UweKEz4P9m8+xyHpqA7Ae1ElZogSvs7YayIiy1NGrUUeH0yIRTtpaYKv4o/0QNirMNxf39HKr Em09En0tDjL8nFHEvUk+IUDGOO4qkfH8767NLmI0vYwgaLh5cHQIJq1NZQwNgcfkf61wPGz1f GDgj6DdVaNJO71JBvD8nHP1Hx8csJhBc+zryMy87up30ZghvVvWXTSUMf78gX6YOa2lrIZzYK Hn0ENFy5GeTDVYSRx68DNmDdEOv/3aY7mcBjR73sFGFCD4SLGvSZeavn+gJY7vigS06Kclbx+ eePpc76hNi/hgfKnn7fFntb9qbSZIk66iIl7LnyOC6hkJMjJmvk9H+Ac+jLj/BIo3XwteRjIQ d06+MUC6pUisjWJHLQJczb4k42OpQRjnJztJWVIHzXsyZ7HVYqmwORNHzlhbnE7+jWIJty2Mp dymO7kquLcBoJFC9Lxuo7SbpG2zFcP7vN1L/9AW6CPmxJHwh8MfKnW3Ir7HkGWdOPRvLK/Y4g 8HQGX+CcLfueUPu+RcIvKThFX4+wMGYiLlyZOZ0nLu1Ql6nXFGclGuS8TYjx6HPOJJR06IbtQ Xi2jDG1FJXquH02lgJejUrvbDNJcD+4NhqZmCWbzohNLvGXvUXxfXHnPXjA1CJIb3h166N6zQ haEb0R1GZcEOKn5IQEebqrdaVQGK9vaSZfxVPX0mPJnn8= X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 69993 Cc: 69993 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.7 (-) > 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'. '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. > 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. martin
bug-gnu-emacs@HIDDEN:bug#69993; Package emacs.
Full text available.
Received: (at 69993) by debbugs.gnu.org; 9 Apr 2024 06:42:56 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Apr 09 02:42:56 2024
Received: from localhost ([127.0.0.1]:48125 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1ru5C3-0000b4-Mw
for submit <at> debbugs.gnu.org; Tue, 09 Apr 2024 02:42:56 -0400
Received: from relay8-d.mail.gandi.net ([217.70.183.201]:58119)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <juri@HIDDEN>) id 1ru5By-0000Zl-2Z
for 69993 <at> debbugs.gnu.org; Tue, 09 Apr 2024 02:42:53 -0400
Received: by mail.gandi.net (Postfix) with ESMTPSA id 1571F1BF20F;
Tue, 9 Apr 2024 06:42:35 +0000 (UTC)
From: Juri Linkov <juri@HIDDEN>
To: martin rudalics <rudalics@HIDDEN>
Subject: Re: bug#69993: Wrap window buffers while cycling
In-Reply-To: <85109880-3370-47e0-b7c9-6c5a32cfaafa@HIDDEN> (martin rudalics's
message of "Sun, 7 Apr 2024 10:23:16 +0200")
Organization: LINKOV.NET
References: <86h6gug41x.fsf@HIDDEN>
<5c71ea64-0f97-4b90-af61-1156fe33f1ea@HIDDEN>
<86cyreu78w.fsf@HIDDEN>
<463c9242-56ef-4c99-9fe6-4b70be2071b2@HIDDEN>
<86sf0abeg3.fsf@HIDDEN>
<f3c9969f-64a0-491b-a5a8-7417a2cb9d45@HIDDEN>
<86v855ggkv.fsf@HIDDEN>
<91327e7b-d0a5-4f3a-a1f8-218d118608d6@HIDDEN>
<86sf07bnl4.fsf@HIDDEN>
<efd1b8d1-cec3-4e18-8aba-7fc2db9edaba@HIDDEN>
<86v850jmmo.fsf@HIDDEN>
<0d2fdebf-2149-4f92-89b8-45a8b6a7d272@HIDDEN>
<86plv8hz2v.fsf@HIDDEN>
<8a131d8b-1330-4d82-92f6-309f499e9c15@HIDDEN>
<86h6gi49zw.fsf@HIDDEN>
<1e50bd70-8cbb-46f9-9078-dd0e6226da63@HIDDEN>
<861q7k8gms.fsf@HIDDEN>
<2d3f0d14-e39b-4399-be30-03f11725c505@HIDDEN>
<86ttkf6a8r.fsf@HIDDEN> <86jzlajpqq.fsf@HIDDEN>
<85109880-3370-47e0-b7c9-6c5a32cfaafa@HIDDEN>
Date: Tue, 09 Apr 2024 09:35:21 +0300
Message-ID: <86le5nhwqy.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/30.0.50 (x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain
X-GND-Sasl: juri@HIDDEN
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 69993
Cc: 69993 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)
>> The decision whether to support wrapping for 'switch-to-prev-buffer'
>> could depend on whether users who don't use the tab-line need it?
>
> Currently, 'switch-to-prev-buffer' always wraps. So it misses two
> features:
>
> - Inhibit wrapping.
>
> - Restrict itself to the buffers shown in that window only.
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.
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)))
bug-gnu-emacs@HIDDEN:bug#69993; Package emacs.
Full text available.
Received: (at 69993) by debbugs.gnu.org; 7 Apr 2024 08:23:35 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Apr 07 04:23:35 2024
Received: from localhost ([127.0.0.1]:41539 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1rtNoN-0005B7-Af
for submit <at> debbugs.gnu.org; Sun, 07 Apr 2024 04:23:35 -0400
Received: from mout.gmx.net ([212.227.17.22]:33939)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <rudalics@HIDDEN>) id 1rtNoI-0005AT-3y
for 69993 <at> debbugs.gnu.org; Sun, 07 Apr 2024 04:23:34 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.at;
s=s31663417; t=1712478196; x=1713082996; i=rudalics@HIDDEN;
bh=V8V1/seyjwlFN3FQ5nKKnBJJ0dqKP+C0YYMOxaS+k1U=;
h=X-UI-Sender-Class:Date:Subject:To:Cc:References:From:
In-Reply-To;
b=MxTAK3IU9b3WMXtB1kRYwkl83O396NqppV1cPweYlFd4jvnVQ7mQgDedeNmFg0ei
sUjXo0HHszdpq+EFCd0fK5yYmDWXYz02JrvkBeRLizPPFjwmnQG8HVmkL4/IGXGtY
4xvYKMJuH/qo/R4uP3PU1qbH6dIQLcOUuq/4SOSaYMAZQ/XxsIOfC+Kb96089Lbhy
DCRN8JOiJucUNdpjcO8UsOCyZWC9lVN/gJVYFZRLhZK9StFFJjg8cnIYXowxljCrs
EpQxuZKraFPX1GV/WbQiWKaeBI+ealR2pqz2WOIrlJnRCZG2p3ONRzu6NMNmkO5J3
CHyYyzg/wK8OEIwliw==
X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a
Received: from [192.168.31.113] ([212.95.5.44]) by mail.gmx.net (mrgmx105
[212.227.17.168]) with ESMTPSA (Nemesis) id 1MhU5b-1sO1SR366V-00ebJD; Sun, 07
Apr 2024 10:23:16 +0200
Message-ID: <85109880-3370-47e0-b7c9-6c5a32cfaafa@HIDDEN>
Date: Sun, 7 Apr 2024 10:23:16 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: bug#69993: Wrap window buffers while cycling
To: Juri Linkov <juri@HIDDEN>
References: <86h6gug41x.fsf@HIDDEN>
<c2258795-4352-46af-85d3-0a4f1ba3d261@HIDDEN>
<86h6gs2lk7.fsf@HIDDEN>
<5c71ea64-0f97-4b90-af61-1156fe33f1ea@HIDDEN>
<86cyreu78w.fsf@HIDDEN>
<463c9242-56ef-4c99-9fe6-4b70be2071b2@HIDDEN>
<86sf0abeg3.fsf@HIDDEN>
<f3c9969f-64a0-491b-a5a8-7417a2cb9d45@HIDDEN>
<86v855ggkv.fsf@HIDDEN>
<91327e7b-d0a5-4f3a-a1f8-218d118608d6@HIDDEN>
<86sf07bnl4.fsf@HIDDEN>
<efd1b8d1-cec3-4e18-8aba-7fc2db9edaba@HIDDEN>
<86v850jmmo.fsf@HIDDEN>
<0d2fdebf-2149-4f92-89b8-45a8b6a7d272@HIDDEN>
<86plv8hz2v.fsf@HIDDEN>
<8a131d8b-1330-4d82-92f6-309f499e9c15@HIDDEN>
<86h6gi49zw.fsf@HIDDEN>
<1e50bd70-8cbb-46f9-9078-dd0e6226da63@HIDDEN>
<861q7k8gms.fsf@HIDDEN>
<2d3f0d14-e39b-4399-be30-03f11725c505@HIDDEN>
<86ttkf6a8r.fsf@HIDDEN> <86jzlajpqq.fsf@HIDDEN>
Content-Language: en-US
From: martin rudalics <rudalics@HIDDEN>
In-Reply-To: <86jzlajpqq.fsf@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K1:mYGRFSHKOr41fn3PqnT/t9gPEL1o5o8DUpxdn+2mI9J1qxqI2gb
Te1M5O+IBdnfDoP/yfT4lRt3WRNbbwbNmH3ushKjUg8YeBaXNLUh3PHItpOrbmq0SA+1czE
EwPpiqSg00f8NJLXVjZgS3pitOCXrlZ7nMiCJi8mIIIUaonAu4QG60nz/hLV8Ig021IcWB7
NW0mWJSlPgT1qiR+dVoYg==
X-Spam-Flag: NO
UI-OutboundReport: notjunk:1;M01:P0:0tt+Amuxjec=;JwGI+EcmbxZaHQ7b0sfCYyWH8OH
mLSJPWgM9MR0Kr1fR45vA4Ur4S8BWqW/aQgyYZvz+UcDUy4sP3lbfujWrkOtZwVMDtB2yZgWl
54JawtdUDNHRFQlCWVVYc2Ysgtxl26dnL115poXE+Gp/k7xDy/Zwvn1x4j6ATACxthxyJBMWq
YIhvUA6ua3dhdyUnVWLVZPmwA0930uelGtKNUYWLOGAqzFbTpdeqmeZjR2qLCvwQGTY1BUrxg
uVXFkBPQOqapxN8nVX2aYecrGFtuhZr1ZsGz8PyNH4LrKiut7x0k0SPTxNf8mGIGDwsONecVK
FMasH9nWtbqpo/aLK6jx8b51BHeTUFAjZ7owt+eXhKf76JI8xRMc7Gxy1tNP02bGueqC5TEOj
hmKoWhSuqAFVshYHbihpLvpkud8mnP6+8KTmlvcpnioeW8QD/wlwK7l2evN9AB4PFne5yxDK7
yjLPndTrL25BNM1rnwNkY3W0WWOZ436oiF5iFv7Afa++8qs17DoQFfST6kg64JBGLe1s9pGb1
PwQ5umK2kVS7bHg3wShj1PIaB96pB8pOhXIqfjKjAn54pdpQwrqQ6F3JdZmeCzkf/0vuq6vIg
SFIoWOQ6BilIUfk5FaGIGqO/cXCET4Ru0dOXGq58m1dGdM6c3XlaaWMeIKrny9GK2cxTiuVag
S5gE20SRtIKE4D4s6iDpBNAg1ntEaauCRpZMf+3tNNherDyydNN/JYUwWl05YV8F0G3/gJRCc
lF/5kggTTBRPl4KpQuqnpY35wln89cf7esj0gTz2quyIX0+/o8O9qRO0TuyxQsChPjNRCdI9F
tgghU+4saGKTNhkOzIF0D870gLRRr9lQD66SPTMWAJfz3EXnEXcohBmvqt5HjJljqa
X-Spam-Score: 2.9 (++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
has NOT identified this incoming email as spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
the administrator of that system for details.
Content preview: > The decision whether to support wrapping for
'switch-to-prev-buffer'
> could depend on whether users who don't use the tab-line need it? Currently,
'switch-to-prev-buffer' always wraps. So it misses two features:
Content analysis details: (2.9 points, 10.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
3.6 RCVD_IN_SBL_CSS RBL: Received via a relay in Spamhaus SBL-CSS
[212.95.5.44 listed in zen.spamhaus.org]
-0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2)
[212.227.17.22 listed in wl.mailspike.net]
-0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at https://www.dnswl.org/,
low trust [212.227.17.22 listed in list.dnswl.org]
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail
provider (rudalics[at]gmx.at)
0.0 T_SPF_TEMPERROR SPF: test of record failed (temperror)
0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record
X-Debbugs-Envelope-To: 69993
Cc: 69993 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 1.9 (+)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
has NOT identified this incoming email as spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
the administrator of that system for details.
Content preview: > The decision whether to support wrapping for 'switch-to-prev-buffer'
> could depend on whether users who don't use the tab-line need it? Currently,
'switch-to-prev-buffer' always wraps. So it misses two features:
Content analysis details: (1.9 points, 10.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
-0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at https://www.dnswl.org/,
low trust
[212.227.17.22 listed in list.dnswl.org]
3.6 RCVD_IN_SBL_CSS RBL: Received via a relay in Spamhaus SBL-CSS
[212.95.5.44 listed in zen.spamhaus.org]
-0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2)
[212.227.17.22 listed in wl.mailspike.net]
-0.0 SPF_PASS SPF: sender matches SPF record
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail
provider (rudalics[at]gmx.at)
0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record
-1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list
manager
> The decision whether to support wrapping for 'switch-to-prev-buffer'
> could depend on whether users who don't use the tab-line need it?
Currently, 'switch-to-prev-buffer' always wraps. So it misses two
features:
- Inhibit wrapping.
- Restrict itself to the buffers shown in that window only.
martin
bug-gnu-emacs@HIDDEN:bug#69993; Package emacs.
Full text available.Received: (at 69993) by debbugs.gnu.org; 6 Apr 2024 18:45:56 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Apr 06 14:45:56 2024 Received: from localhost ([127.0.0.1]:40960 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1rtB35-000222-TK for submit <at> debbugs.gnu.org; Sat, 06 Apr 2024 14:45:56 -0400 Received: from relay2-d.mail.gandi.net ([217.70.183.194]:51281) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <juri@HIDDEN>) id 1rtB31-0001ej-O2 for 69993 <at> debbugs.gnu.org; Sat, 06 Apr 2024 14:45:52 -0400 Received: by mail.gandi.net (Postfix) with ESMTPSA id BC42640002; Sat, 6 Apr 2024 18:45:38 +0000 (UTC) From: Juri Linkov <juri@HIDDEN> To: martin rudalics <rudalics@HIDDEN> Subject: Re: bug#69993: Wrap window buffers while cycling In-Reply-To: <86ttkf6a8r.fsf@HIDDEN> (Juri Linkov's message of "Fri, 05 Apr 2024 19:32:36 +0300") Organization: LINKOV.NET References: <86h6gug41x.fsf@HIDDEN> <c2258795-4352-46af-85d3-0a4f1ba3d261@HIDDEN> <86h6gs2lk7.fsf@HIDDEN> <5c71ea64-0f97-4b90-af61-1156fe33f1ea@HIDDEN> <86cyreu78w.fsf@HIDDEN> <463c9242-56ef-4c99-9fe6-4b70be2071b2@HIDDEN> <86sf0abeg3.fsf@HIDDEN> <f3c9969f-64a0-491b-a5a8-7417a2cb9d45@HIDDEN> <86v855ggkv.fsf@HIDDEN> <91327e7b-d0a5-4f3a-a1f8-218d118608d6@HIDDEN> <86sf07bnl4.fsf@HIDDEN> <efd1b8d1-cec3-4e18-8aba-7fc2db9edaba@HIDDEN> <86v850jmmo.fsf@HIDDEN> <0d2fdebf-2149-4f92-89b8-45a8b6a7d272@HIDDEN> <86plv8hz2v.fsf@HIDDEN> <8a131d8b-1330-4d82-92f6-309f499e9c15@HIDDEN> <86h6gi49zw.fsf@HIDDEN> <1e50bd70-8cbb-46f9-9078-dd0e6226da63@HIDDEN> <861q7k8gms.fsf@HIDDEN> <2d3f0d14-e39b-4399-be30-03f11725c505@HIDDEN> <86ttkf6a8r.fsf@HIDDEN> Date: Sat, 06 Apr 2024 21:43:57 +0300 Message-ID: <86jzlajpqq.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/30.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-GND-Sasl: juri@HIDDEN X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 69993 Cc: 69993 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.7 (-) >>> So no problem, tab-line.el is the right place since later I could >>> also implement drag'n'drop of tabs to allow manually changing >>> the order of buffers in the window buffers list. >> >> Your are throwing out the child with the bathwater. I think your >> earlier patches for 'switch-to-prev-buffer' and 'switch-to-next-buffer' >> were good. Just the doc of the option was too tab-line specific. > > I don't know, this whole feature was intended to be tab-line specific, > since the window prev/next-buffers are visualized by the tab-line. The decision whether to support wrapping for 'switch-to-prev-buffer' could depend on whether users who don't use the tab-line need it?
bug-gnu-emacs@HIDDEN:bug#69993; Package emacs.
Full text available.Received: (at 69993) by debbugs.gnu.org; 5 Apr 2024 16:33:28 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Apr 05 12:33:28 2024 Received: from localhost ([127.0.0.1]:37400 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1rsmVL-0005BY-Q3 for submit <at> debbugs.gnu.org; Fri, 05 Apr 2024 12:33:28 -0400 Received: from relay8-d.mail.gandi.net ([217.70.183.201]:56723) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <juri@HIDDEN>) id 1rsmVK-0005Af-5g for 69993 <at> debbugs.gnu.org; Fri, 05 Apr 2024 12:33:27 -0400 Received: by mail.gandi.net (Postfix) with ESMTPSA id 5E5621BF203; Fri, 5 Apr 2024 16:33:12 +0000 (UTC) From: Juri Linkov <juri@HIDDEN> To: martin rudalics <rudalics@HIDDEN> Subject: Re: bug#69993: Wrap window buffers while cycling In-Reply-To: <2d3f0d14-e39b-4399-be30-03f11725c505@HIDDEN> (martin rudalics's message of "Fri, 5 Apr 2024 11:08:11 +0200") Organization: LINKOV.NET References: <86h6gug41x.fsf@HIDDEN> <86le66ckhj.fsf@HIDDEN> <c2258795-4352-46af-85d3-0a4f1ba3d261@HIDDEN> <86h6gs2lk7.fsf@HIDDEN> <5c71ea64-0f97-4b90-af61-1156fe33f1ea@HIDDEN> <86cyreu78w.fsf@HIDDEN> <463c9242-56ef-4c99-9fe6-4b70be2071b2@HIDDEN> <86sf0abeg3.fsf@HIDDEN> <f3c9969f-64a0-491b-a5a8-7417a2cb9d45@HIDDEN> <86v855ggkv.fsf@HIDDEN> <91327e7b-d0a5-4f3a-a1f8-218d118608d6@HIDDEN> <86sf07bnl4.fsf@HIDDEN> <efd1b8d1-cec3-4e18-8aba-7fc2db9edaba@HIDDEN> <86v850jmmo.fsf@HIDDEN> <0d2fdebf-2149-4f92-89b8-45a8b6a7d272@HIDDEN> <86plv8hz2v.fsf@HIDDEN> <8a131d8b-1330-4d82-92f6-309f499e9c15@HIDDEN> <86h6gi49zw.fsf@HIDDEN> <1e50bd70-8cbb-46f9-9078-dd0e6226da63@HIDDEN> <861q7k8gms.fsf@HIDDEN> <2d3f0d14-e39b-4399-be30-03f11725c505@HIDDEN> Date: Fri, 05 Apr 2024 19:32:36 +0300 Message-ID: <86ttkf6a8r.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/30.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-GND-Sasl: juri@HIDDEN X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 69993 Cc: 69993 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.7 (-) >> So no problem, tab-line.el is the right place since later I could >> also implement drag'n'drop of tabs to allow manually changing >> the order of buffers in the window buffers list. > > Your are throwing out the child with the bathwater. I think your > earlier patches for 'switch-to-prev-buffer' and 'switch-to-next-buffer' > were good. Just the doc of the option was too tab-line specific. I don't know, this whole feature was intended to be tab-line specific, since the window prev/next-buffers are visualized by the tab-line.
bug-gnu-emacs@HIDDEN:bug#69993; Package emacs.
Full text available.
Received: (at 69993) by debbugs.gnu.org; 5 Apr 2024 09:08:27 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Apr 05 05:08:27 2024
Received: from localhost ([127.0.0.1]:35192 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1rsfYg-0004fi-Cg
for submit <at> debbugs.gnu.org; Fri, 05 Apr 2024 05:08:27 -0400
Received: from mout.gmx.net ([212.227.15.19]:35431)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <rudalics@HIDDEN>) id 1rsfYe-0004el-5g
for 69993 <at> debbugs.gnu.org; Fri, 05 Apr 2024 05:08:25 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.at;
s=s31663417; t=1712308092; x=1712912892; i=rudalics@HIDDEN;
bh=tG05LhfUgW2vvPSNOcsXke6VrzTTSEjksH42geiakhE=;
h=X-UI-Sender-Class:Date:Subject:To:Cc:References:From:
In-Reply-To;
b=k/DjwV1A72NuFjLFDn33aNTbUb5LwU/wN7SsA+7m1Cwj36gAWhm9ydcTXpaXVJ0A
RpRI9KsARdLpJx68f5R0R09iCO3MpdYh92mWEmaFD6fndL0twDCSr9xnQJtxJIdm1
7K5G4QTeCABoI4LuQ2rqoTEvMrCb5jLLjBwyFt7gWrdn+hquRdSAXI/F8I7dccOrO
2BaGErOSe8dZGhhYXHqLZjwCjKmPhbhzuz0skdO7qbRZHTO70QT/+34cMIo8sAI5L
+eSqYGzU7zTq64/LJDjtlnprcwHVSIaAl0dsyMKPM6WmaH8yXXsSmKdMWH8RlYCKZ
OFJA83v+xCd/uX6zJQ==
X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a
Received: from [192.168.31.113] ([213.142.97.167]) by mail.gmx.net (mrgmx004
[212.227.17.190]) with ESMTPSA (Nemesis) id 1MIdiZ-1s4R7B1nxl-00EhXo; Fri, 05
Apr 2024 11:08:12 +0200
Message-ID: <2d3f0d14-e39b-4399-be30-03f11725c505@HIDDEN>
Date: Fri, 5 Apr 2024 11:08:11 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: bug#69993: Wrap window buffers while cycling
To: Juri Linkov <juri@HIDDEN>
References: <86h6gug41x.fsf@HIDDEN>
<3419df35-1b96-4a64-8ed7-722a05c58742@HIDDEN>
<86le66ckhj.fsf@HIDDEN>
<c2258795-4352-46af-85d3-0a4f1ba3d261@HIDDEN>
<86h6gs2lk7.fsf@HIDDEN>
<5c71ea64-0f97-4b90-af61-1156fe33f1ea@HIDDEN>
<86cyreu78w.fsf@HIDDEN>
<463c9242-56ef-4c99-9fe6-4b70be2071b2@HIDDEN>
<86sf0abeg3.fsf@HIDDEN>
<f3c9969f-64a0-491b-a5a8-7417a2cb9d45@HIDDEN>
<86v855ggkv.fsf@HIDDEN>
<91327e7b-d0a5-4f3a-a1f8-218d118608d6@HIDDEN>
<86sf07bnl4.fsf@HIDDEN>
<efd1b8d1-cec3-4e18-8aba-7fc2db9edaba@HIDDEN>
<86v850jmmo.fsf@HIDDEN>
<0d2fdebf-2149-4f92-89b8-45a8b6a7d272@HIDDEN>
<86plv8hz2v.fsf@HIDDEN>
<8a131d8b-1330-4d82-92f6-309f499e9c15@HIDDEN>
<86h6gi49zw.fsf@HIDDEN>
<1e50bd70-8cbb-46f9-9078-dd0e6226da63@HIDDEN>
<861q7k8gms.fsf@HIDDEN>
Content-Language: en-US
From: martin rudalics <rudalics@HIDDEN>
In-Reply-To: <861q7k8gms.fsf@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K1:TItO/FBLeuwmkPbmJBjsBMSkoDvBnhCLLKrDfHxS/4HvPvn6Sde
YZJ6tyBuOgZ3nSV58UWrEBpPMQeOSRfcEDT9SsskWZfk6yGGS4Qp76EG5cxgmf64bng8NfU
KPIU+WGJDNt/YWuSW562ry7COVx4XMhI9xnfpFJFUvQ1fLn/fW0p2hKvTBZeDDKqlwJjLuF
dPxLI2boF6WgsTROETqHw==
X-Spam-Flag: NO
UI-OutboundReport: notjunk:1;M01:P0:6A3qPs6U4aE=;NdNzgeBWQ6Vq0FjFDNtZfC46Tfy
dCx4/6aAy6hYdNBAwBhbVyAWFVUjL/Ntuh3iyaiWRXcNNHaIOd3w94yl3YbQLPUoOoqLjRyuq
Vrd5XYyzGpukQZnJ+azcF5Jwl6HU31N9Q/M/md6Yo+UMJ9AMTN6I3FTeJvZmBxgNamNqwNAvl
CxQy6SL1vSG19kLm2HZy8frZZcPHOS81pb8BiL2FZQcjTy+G4mWDFzeib2JnJueEQ9sS3fLyf
aNezRXHmR7i0czJ7ryHWffWAhfjecjKCGoiLRFuF5jMrGOlHG6peEo33yBgBInN0eGLQij1sv
X5Ugw6kV5SnZ8GsClPA1+ndVkhmOzbYZJD0pC0pVFuc2F9x/H5q15I3oa341ZP987F3ynnrmG
ofSbanlgm7x2bEWDOpBJrdVgE73Kh5oaFHl3OMF4nHufIMeuppde89aYRx4dDuvsencwyz/fl
Qe95q0GeuER+EcOAgMU4baXN4XvA9s/C2NjoEx9uEgdy7FnqU8MchCiRcJPol/IxOxTvXfnz4
H+mKRyz9CHK3Ruu4wCLz+NwTLJQkW+xFL5+QrgsIeJ2KQWiV82zHWdiLnlqcIjeacfUjWI8ta
nmDSLQOSCs7RVA6E9UPqJzVG1ouNLDzA1lA09udGTna18DINghoVLO9oau37OH4Ph+MmyTM9z
aS5QNq2lYncxt+DNY/RkVkR8vsk4+O2GBzDvZzF4vTNzTYT1BMT54KXMbshET2YudbY6a4fVj
Xghbj5NPWbkp47FMj9jTVGOtI1G8fcpzpdeviDnUY8PXOk985G6vOX0OOdPDuI2VBUQzAgzio
X7RFRXi0ZSLdR96HZocbyMkrsAe/vH1Iyw2TBe/mRwUrQ=
X-Spam-Score: 2.9 (++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
has NOT identified this incoming email as spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
the administrator of that system for details.
Content preview: > So no problem, tab-line.el is the right place since later
I could > also implement drag'n'drop of tabs to allow manually changing >
the order of buffers in the window buffers list. Your are throwing out the
child with the bathwater. I think your earlier patches for
'switch-to-prev-buffer'
and 'switch-to-next-buffer' were good. Just the doc of the option was too
tab-line specific [...]
Content analysis details: (2.9 points, 10.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
-0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at https://www.dnswl.org/,
low trust [212.227.15.19 listed in list.dnswl.org]
3.6 RCVD_IN_SBL_CSS RBL: Received via a relay in Spamhaus SBL-CSS
[213.142.97.167 listed in zen.spamhaus.org]
-0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2)
[212.227.15.19 listed in wl.mailspike.net]
-0.0 SPF_PASS SPF: sender matches SPF record
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail
provider (rudalics[at]gmx.at)
0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record
X-Debbugs-Envelope-To: 69993
Cc: 69993 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 1.9 (+)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
has NOT identified this incoming email as spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
the administrator of that system for details.
Content preview: > So no problem, tab-line.el is the right place since later
I could > also implement drag'n'drop of tabs to allow manually changing >
the order of buffers in the window buffers list. Your are throwing out the
child with the bathwater. I think your earlier patches for 'switch-to-prev-buffer'
and 'switch-to-next-buffer' were good. Just the doc of the option was too
tab-line specific [...]
Content analysis details: (1.9 points, 10.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
-0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at https://www.dnswl.org/,
low trust
[212.227.15.19 listed in list.dnswl.org]
3.6 RCVD_IN_SBL_CSS RBL: Received via a relay in Spamhaus SBL-CSS
[213.142.97.167 listed in zen.spamhaus.org]
-0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2)
[212.227.15.19 listed in wl.mailspike.net]
-0.0 SPF_PASS SPF: sender matches SPF record
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail
provider (rudalics[at]gmx.at)
0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record
-1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list
manager
> So no problem, tab-line.el is the right place since later I could
> also implement drag'n'drop of tabs to allow manually changing
> the order of buffers in the window buffers list.
Your are throwing out the child with the bathwater. I think your
earlier patches for 'switch-to-prev-buffer' and 'switch-to-next-buffer'
were good. Just the doc of the option was too tab-line specific.
martin
bug-gnu-emacs@HIDDEN:bug#69993; Package emacs.
Full text available.
Received: (at 69993) by debbugs.gnu.org; 5 Apr 2024 06:49:36 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Apr 05 02:49:36 2024
Received: from localhost ([127.0.0.1]:35125 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1rsdOK-0003UJ-7r
for submit <at> debbugs.gnu.org; Fri, 05 Apr 2024 02:49:36 -0400
Received: from relay1-d.mail.gandi.net ([2001:4b98:dc4:8::221]:48101)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <juri@HIDDEN>) id 1rsdOF-0003TR-52
for 69993 <at> debbugs.gnu.org; Fri, 05 Apr 2024 02:49:34 -0400
Received: by mail.gandi.net (Postfix) with ESMTPSA id 169D1240005;
Fri, 5 Apr 2024 06:49:17 +0000 (UTC)
From: Juri Linkov <juri@HIDDEN>
To: martin rudalics <rudalics@HIDDEN>
Subject: Re: bug#69993: Wrap window buffers while cycling
In-Reply-To: <1e50bd70-8cbb-46f9-9078-dd0e6226da63@HIDDEN> (martin rudalics's
message of "Thu, 4 Apr 2024 10:03:28 +0200")
Organization: LINKOV.NET
References: <86h6gug41x.fsf@HIDDEN>
<3419df35-1b96-4a64-8ed7-722a05c58742@HIDDEN>
<86le66ckhj.fsf@HIDDEN>
<c2258795-4352-46af-85d3-0a4f1ba3d261@HIDDEN>
<86h6gs2lk7.fsf@HIDDEN>
<5c71ea64-0f97-4b90-af61-1156fe33f1ea@HIDDEN>
<86cyreu78w.fsf@HIDDEN>
<463c9242-56ef-4c99-9fe6-4b70be2071b2@HIDDEN>
<86sf0abeg3.fsf@HIDDEN>
<f3c9969f-64a0-491b-a5a8-7417a2cb9d45@HIDDEN>
<86v855ggkv.fsf@HIDDEN>
<91327e7b-d0a5-4f3a-a1f8-218d118608d6@HIDDEN>
<86sf07bnl4.fsf@HIDDEN>
<efd1b8d1-cec3-4e18-8aba-7fc2db9edaba@HIDDEN>
<86v850jmmo.fsf@HIDDEN>
<0d2fdebf-2149-4f92-89b8-45a8b6a7d272@HIDDEN>
<86plv8hz2v.fsf@HIDDEN>
<8a131d8b-1330-4d82-92f6-309f499e9c15@HIDDEN>
<86h6gi49zw.fsf@HIDDEN>
<1e50bd70-8cbb-46f9-9078-dd0e6226da63@HIDDEN>
Date: Fri, 05 Apr 2024 09:45:46 +0300
Message-ID: <861q7k8gms.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/30.0.50 (x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain
X-GND-Sasl: juri@HIDDEN
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 69993
Cc: 69993 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)
>>> (defcustom switch-to-prev-buffer-wrap nil
>>
>> The only problem is that this doesn't mention wrapping.
>
> Isn't the paragraph starting with "If this is t, ..." enough?
No, because this feature is about wrapping buffers
visible on the tab-line.
>>> 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.
Ok, since this feature is intended for the users of the tab-line, who
intuitively understand what it's doing, so it's not confusing for them,
here is what I'm going to do: I'll rebind 'C-x C-left' and 'C-x C-right'
in 'tab-line-mode' and will use tab-line functions to implement wrapping
of visible tabs/buffers. Basically this means just adding a new map:
(defvar-keymap tab-line-mode-map
"C-x <left>" #'tab-line-switch-to-prev-tab
"C-x C-<left>" #'tab-line-switch-to-prev-tab
"C-x <right>" #'tab-line-switch-to-next-tab
"C-x C-<right>" #'tab-line-switch-to-next-tab)
So no problem, tab-line.el is the right place since later I could
also implement drag'n'drop of tabs to allow manually changing
the order of buffers in the window buffers list.
bug-gnu-emacs@HIDDEN:bug#69993; Package emacs.
Full text available.
Received: (at 69993) by debbugs.gnu.org; 4 Apr 2024 08:03:45 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Apr 04 04:03:45 2024
Received: from localhost ([127.0.0.1]:60446 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1rsI4V-0006Tv-SY
for submit <at> debbugs.gnu.org; Thu, 04 Apr 2024 04:03:44 -0400
Received: from mout.gmx.net ([212.227.15.18]:52843)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <rudalics@HIDDEN>) id 1rsI4S-0006T5-Oe
for 69993 <at> debbugs.gnu.org; Thu, 04 Apr 2024 04:03:42 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.at;
s=s31663417; t=1712217809; x=1712822609; i=rudalics@HIDDEN;
bh=Zk0fUsFLWzHndrK1TZPCiDiAznCyv2gLDL5tOygfrVE=;
h=X-UI-Sender-Class:Date:Subject:To:Cc:References:From:
In-Reply-To;
b=kXQWQe+iyEkRG8oGmGpSvBevMbCv6ewXTo8TePXllzPzm6ofSLeqFzOGHcrQ6MVf
qKam6NgFdnXkL5ZieFeGbHTF3EatKvMcCmmArghnvplT2wIudvgsiW+KVnpXjVOQV
P74guajBaeaziBedY2piVDJfe4ZmBVRGOhq5IUiEct9l6CMgWOhW0/MJdhhZNyluy
6U5u6VMGxnIwfGrmqRSsggU1gmI5oLVmkRhi0O28XG35PjumiHrlWHYt3glbku1tA
iT+GGwSAulFIJGCUk0qaBbC4RfiGWyuMXea0ZNfgBedVVzliqtI+GeeGPw+cnlAjN
vbVEQVog94KSYIr+Iw==
X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a
Received: from [192.168.31.113] ([212.95.5.97]) by mail.gmx.net (mrgmx004
[212.227.17.190]) with ESMTPSA (Nemesis) id 1N7R1T-1stKov3r5B-017mDo; Thu, 04
Apr 2024 10:03:29 +0200
Message-ID: <1e50bd70-8cbb-46f9-9078-dd0e6226da63@HIDDEN>
Date: Thu, 4 Apr 2024 10:03:28 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: bug#69993: Wrap window buffers while cycling
To: Juri Linkov <juri@HIDDEN>
References: <86h6gug41x.fsf@HIDDEN>
<3419df35-1b96-4a64-8ed7-722a05c58742@HIDDEN>
<86le66ckhj.fsf@HIDDEN>
<c2258795-4352-46af-85d3-0a4f1ba3d261@HIDDEN>
<86h6gs2lk7.fsf@HIDDEN>
<5c71ea64-0f97-4b90-af61-1156fe33f1ea@HIDDEN>
<86cyreu78w.fsf@HIDDEN>
<463c9242-56ef-4c99-9fe6-4b70be2071b2@HIDDEN>
<86sf0abeg3.fsf@HIDDEN>
<f3c9969f-64a0-491b-a5a8-7417a2cb9d45@HIDDEN>
<86v855ggkv.fsf@HIDDEN>
<91327e7b-d0a5-4f3a-a1f8-218d118608d6@HIDDEN>
<86sf07bnl4.fsf@HIDDEN>
<efd1b8d1-cec3-4e18-8aba-7fc2db9edaba@HIDDEN>
<86v850jmmo.fsf@HIDDEN>
<0d2fdebf-2149-4f92-89b8-45a8b6a7d272@HIDDEN>
<86plv8hz2v.fsf@HIDDEN>
<8a131d8b-1330-4d82-92f6-309f499e9c15@HIDDEN>
<86h6gi49zw.fsf@HIDDEN>
Content-Language: en-US
From: martin rudalics <rudalics@HIDDEN>
In-Reply-To: <86h6gi49zw.fsf@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K1:mjIBH7mtl1+VcJrdFKf713ATeTu5TgCng6lLA38VVOQCiJD2qLB
U6eKmuiJKBvxWMi+LWvdL8R463pi3vRRK4RQXiz6tW5jMYB8xL3awPC8YD/lNajRQkza0W+
rFvxcR2cp9UR1UWJ/yRJNJ176MkLpxAx2mlNmeEoE9e99Hf2PX5zMW8BWrlOSuxLG8IcCSG
iV1by8xdsNQzGDTAr+hMg==
X-Spam-Flag: NO
UI-OutboundReport: notjunk:1;M01:P0:hI03BgbqqV4=;jSECduhzxqyFh6dlBR0iJHf7z/Z
0xxN2LjL8mdG2jfjPXscPm8pFyYcyylnEAp5sH75KWMeo3u9CoRbPf9NosHDs78PKeWWupHBQ
4rGlgMD/bUR3axZYuqPQjykKfaPN9XrjKrWsN2CcAISVVmirG86tCqehTvLNvIlO+5/LP4zzf
xmt8Gmkxeg9OAVyfTYKrSPoc6ThR07iZRi3KaaFxp0QYWP9IyEc63BVLpsnC7PuSxCJp+zd+n
JQev3hGy0iFTeeoW/KNWPMn+xzfU34ajkaenxe27Z85vbAGPjrgfm5tW7aKCY4fs6YmVhjt/P
bHvaeZDAiOkipFU/ZrSZWo+9/IqxgxNfHy7HjZfz4Eh7f/vrA7V0SO7f4Eqp9ojX2zZ0W6zLp
3J9AKROkF31dQpQJHQvuL5Jz9qG7b8mlOz44uwkl43GYED6u6nKsg6gNT12ET0lbEfTGuNuiR
FvzU5wFbJ3B4J9Qk3N0+qURb5E0ao59LYH1r83CbwcteYwUhYt5x6iYfdV8W9NXNWOB3di67I
cV4M+1mdp8Yhmw6wkCIBgm7MFM4blUFU9wk5JKoojVCTx0DhvGKnvEib6JMT6zOHZvyJSQ8dd
Sx9Tl2lKoGoHeNWv6MqeW5ATOf3CnkosYFqve4+g6uH2dsyhpk5IUO/GOV3TOWO3fRuaamVLF
5r0ogQx5yZVjxw48pXq35dMcCH0eNq4ZgrWTmIY212To/bKxWCJGkze7YW4w+x7z7x3sO4TXr
GSECIv+IyH8ItGIwKWSGFl+oeK1NZwgg4nxJOTJo0xrG3w46cUdJg+kko+jzuBVQ7fbhsGmjl
aadI9A0Zs1Q9wIjj9I9cnuhc1SY9BQmtngmzdw6LeIBWU=
X-Spam-Score: 2.9 (++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
has NOT identified this incoming email as spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
the administrator of that system for details.
Content preview: >> (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-n [...]
Content analysis details: (2.9 points, 10.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
3.6 RCVD_IN_SBL_CSS RBL: Received via a relay in Spamhaus SBL-CSS
[212.95.5.97 listed in zen.spamhaus.org]
-0.0 SPF_PASS SPF: sender matches SPF record
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail
provider (rudalics[at]gmx.at)
0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record
-0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2)
[212.227.15.18 listed in wl.mailspike.net]
-0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at https://www.dnswl.org/,
low trust [212.227.15.18 listed in list.dnswl.org]
X-Debbugs-Envelope-To: 69993
Cc: 69993 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 1.9 (+)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
has NOT identified this incoming email as spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
the administrator of that system for details.
Content preview: >> (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-n [...]
Content analysis details: (1.9 points, 10.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
-0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at https://www.dnswl.org/,
low trust
[212.227.15.18 listed in list.dnswl.org]
3.6 RCVD_IN_SBL_CSS RBL: Received via a relay in Spamhaus SBL-CSS
[212.95.5.97 listed in zen.spamhaus.org]
-0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2)
[212.227.15.18 listed in wl.mailspike.net]
-0.0 SPF_PASS SPF: sender matches SPF record
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail
provider (rudalics[at]gmx.at)
0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record
-1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list
manager
>> (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
bug-gnu-emacs@HIDDEN:bug#69993; Package emacs.
Full text available.Received: (at 69993) by debbugs.gnu.org; 4 Apr 2024 06:24:41 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Apr 04 02:24:41 2024 Received: from localhost ([127.0.0.1]:60389 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1rsGWf-0005Cf-G1 for submit <at> debbugs.gnu.org; Thu, 04 Apr 2024 02:24:41 -0400 Received: from relay3-d.mail.gandi.net ([2001:4b98:dc4:8::223]:50207) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <juri@HIDDEN>) id 1rsGWb-0005Bm-Sv for 69993 <at> debbugs.gnu.org; Thu, 04 Apr 2024 02:24:40 -0400 Received: by mail.gandi.net (Postfix) with ESMTPSA id 874BC60006; Thu, 4 Apr 2024 06:24:25 +0000 (UTC) From: Juri Linkov <juri@HIDDEN> To: martin rudalics <rudalics@HIDDEN> Subject: Re: bug#69993: Wrap window buffers while cycling In-Reply-To: <86il10geth.fsf@HIDDEN> (Juri Linkov's message of "Tue, 02 Apr 2024 19:34:43 +0300") Organization: LINKOV.NET References: <86h6gug41x.fsf@HIDDEN> <3419df35-1b96-4a64-8ed7-722a05c58742@HIDDEN> <86le66ckhj.fsf@HIDDEN> <c2258795-4352-46af-85d3-0a4f1ba3d261@HIDDEN> <86h6gs2lk7.fsf@HIDDEN> <5c71ea64-0f97-4b90-af61-1156fe33f1ea@HIDDEN> <86cyreu78w.fsf@HIDDEN> <463c9242-56ef-4c99-9fe6-4b70be2071b2@HIDDEN> <86sf0abeg3.fsf@HIDDEN> <f3c9969f-64a0-491b-a5a8-7417a2cb9d45@HIDDEN> <86v855ggkv.fsf@HIDDEN> <91327e7b-d0a5-4f3a-a1f8-218d118608d6@HIDDEN> <86sf07bnl4.fsf@HIDDEN> <efd1b8d1-cec3-4e18-8aba-7fc2db9edaba@HIDDEN> <86v850jmmo.fsf@HIDDEN> <0d2fdebf-2149-4f92-89b8-45a8b6a7d272@HIDDEN> <86il10geth.fsf@HIDDEN> Date: Thu, 04 Apr 2024 09:22:29 +0300 Message-ID: <86r0fltzoa.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/30.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-GND-Sasl: juri@HIDDEN X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 69993 Cc: 69993 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.7 (-) >> Think only of 'switch-to-buffer-obey-display-actions'. > > Thanks for reminding about 'switch-to-buffer-obey-display-actions'. > This means that all uses of 'switch-to-buffer' in tab-line.el are wrong > and should be replaced with 'set-window-buffer'. > > Or 'switch-to-buffer' still does necessary things? > Then maybe better to wrap 'switch-to-buffer' calls with > > (let ((switch-to-buffer-obey-display-actions nil)) > (switch-to-buffer buffer)) Ok, now fixed this in tab-line.el.
bug-gnu-emacs@HIDDEN:bug#69993; Package emacs.
Full text available.Received: (at 69993) by debbugs.gnu.org; 3 Apr 2024 17:46:48 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Apr 03 13:46:48 2024 Received: from localhost ([127.0.0.1]:59494 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1rs4hD-0003II-UK for submit <at> debbugs.gnu.org; Wed, 03 Apr 2024 13:46:48 -0400 Received: from relay3-d.mail.gandi.net ([217.70.183.195]:33913) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <juri@HIDDEN>) id 1rs4h5-00033B-TR for 69993 <at> debbugs.gnu.org; Wed, 03 Apr 2024 13:46:41 -0400 Received: by mail.gandi.net (Postfix) with ESMTPSA id 4665360004; Wed, 3 Apr 2024 17:46:27 +0000 (UTC) From: Juri Linkov <juri@HIDDEN> To: martin rudalics <rudalics@HIDDEN> Subject: Re: bug#69993: Wrap window buffers while cycling In-Reply-To: <8a131d8b-1330-4d82-92f6-309f499e9c15@HIDDEN> (martin rudalics's message of "Wed, 3 Apr 2024 10:24:18 +0200") Organization: LINKOV.NET References: <86h6gug41x.fsf@HIDDEN> <3419df35-1b96-4a64-8ed7-722a05c58742@HIDDEN> <86le66ckhj.fsf@HIDDEN> <c2258795-4352-46af-85d3-0a4f1ba3d261@HIDDEN> <86h6gs2lk7.fsf@HIDDEN> <5c71ea64-0f97-4b90-af61-1156fe33f1ea@HIDDEN> <86cyreu78w.fsf@HIDDEN> <463c9242-56ef-4c99-9fe6-4b70be2071b2@HIDDEN> <86sf0abeg3.fsf@HIDDEN> <f3c9969f-64a0-491b-a5a8-7417a2cb9d45@HIDDEN> <86v855ggkv.fsf@HIDDEN> <91327e7b-d0a5-4f3a-a1f8-218d118608d6@HIDDEN> <86sf07bnl4.fsf@HIDDEN> <efd1b8d1-cec3-4e18-8aba-7fc2db9edaba@HIDDEN> <86v850jmmo.fsf@HIDDEN> <0d2fdebf-2149-4f92-89b8-45a8b6a7d272@HIDDEN> <86plv8hz2v.fsf@HIDDEN> <8a131d8b-1330-4d82-92f6-309f499e9c15@HIDDEN> Date: Wed, 03 Apr 2024 20:45:33 +0300 Message-ID: <86h6gi49zw.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/30.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-GND-Sasl: juri@HIDDEN X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 69993 Cc: 69993 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.7 (-) >> Thanks, so the patch below ignores 'switch-to-prev-buffer-wrap' in >> 'switch-to-prev-buffer' when its argument BURY-OR-KILL is non-nil. > > If I correctly caught your intentions, I'd rather write > > (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. > 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'.
bug-gnu-emacs@HIDDEN:bug#69993; Package emacs.
Full text available.Received: (at 69993) by debbugs.gnu.org; 3 Apr 2024 17:46:44 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Apr 03 13:46:44 2024 Received: from localhost ([127.0.0.1]:59492 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1rs4h8-0003FU-3V for submit <at> debbugs.gnu.org; Wed, 03 Apr 2024 13:46:43 -0400 Received: from relay9-d.mail.gandi.net ([2001:4b98:dc4:8::229]:49243) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <juri@HIDDEN>) id 1rs4h4-000316-UQ for 69993 <at> debbugs.gnu.org; Wed, 03 Apr 2024 13:46:39 -0400 Received: by mail.gandi.net (Postfix) with ESMTPSA id 2D977FF808; Wed, 3 Apr 2024 17:46:24 +0000 (UTC) From: Juri Linkov <juri@HIDDEN> To: martin rudalics <rudalics@HIDDEN> Subject: Re: bug#69993: Wrap window buffers while cycling In-Reply-To: <52a0cf2d-de88-4a83-aff5-3665bc2d3aae@HIDDEN> (martin rudalics's message of "Wed, 3 Apr 2024 10:24:34 +0200") Organization: LINKOV.NET References: <86h6gug41x.fsf@HIDDEN> <3419df35-1b96-4a64-8ed7-722a05c58742@HIDDEN> <86le66ckhj.fsf@HIDDEN> <c2258795-4352-46af-85d3-0a4f1ba3d261@HIDDEN> <86h6gs2lk7.fsf@HIDDEN> <5c71ea64-0f97-4b90-af61-1156fe33f1ea@HIDDEN> <86cyreu78w.fsf@HIDDEN> <463c9242-56ef-4c99-9fe6-4b70be2071b2@HIDDEN> <86sf0abeg3.fsf@HIDDEN> <f3c9969f-64a0-491b-a5a8-7417a2cb9d45@HIDDEN> <86v855ggkv.fsf@HIDDEN> <91327e7b-d0a5-4f3a-a1f8-218d118608d6@HIDDEN> <86sf07bnl4.fsf@HIDDEN> <efd1b8d1-cec3-4e18-8aba-7fc2db9edaba@HIDDEN> <86v850jmmo.fsf@HIDDEN> <0d2fdebf-2149-4f92-89b8-45a8b6a7d272@HIDDEN> <86il10geth.fsf@HIDDEN> <52a0cf2d-de88-4a83-aff5-3665bc2d3aae@HIDDEN> Date: Wed, 03 Apr 2024 20:44:32 +0300 Message-ID: <86bk6q49z3.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/30.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-GND-Sasl: juri@HIDDEN X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 69993 Cc: 69993 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.7 (-) >>> 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. >> >> Indeed, this is why I asked to add a new hook after set-window-buffer, >> like the hook record-window-buffer is called before set-window-buffer. > > Are you sure that 'window-buffer-change-functions' can't catch this > already? IIUC all you need is to to know whether the current buffer of > a window does not equal the value returned by 'window-old-buffer' for > that window. Thanks for the suggestion, will try.
bug-gnu-emacs@HIDDEN:bug#69993; Package emacs.
Full text available.Received: (at 69993) by debbugs.gnu.org; 3 Apr 2024 08:24:48 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Apr 03 04:24:47 2024 Received: from localhost ([127.0.0.1]:56986 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1rrvvK-0006FW-Vd for submit <at> debbugs.gnu.org; Wed, 03 Apr 2024 04:24:47 -0400 Received: from mout.gmx.net ([212.227.17.22]:35749) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <rudalics@HIDDEN>) id 1rrvvJ-0006Ek-7Z for 69993 <at> debbugs.gnu.org; Wed, 03 Apr 2024 04:24:45 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.at; s=s31663417; t=1712132675; x=1712737475; i=rudalics@HIDDEN; bh=1yh9oKb3FivbijfoSe48iy3QmlvaI++uUaw5xyqK0PQ=; h=X-UI-Sender-Class:Date:Subject:To:Cc:References:From: In-Reply-To; b=KlYTF3ABm0mR2jJUjjJLphFAwc8uJtHOLCCqboFyUTFR6jE+R33DC8TMO/L70evc 1Er8Zp9cV3juuaBtkqKvcA6n9VdJCHJzEQUSbFXMvKNG9Pc80NLGu7SSe71EMHBqf Jt4rHeiBjGVMiEeorUEO8AYcYIVmJOTGxWE9KNYcQScETOppBpj26DxH9AmFJZFAB HBmHbvE+0HeGKHIU1tct+WDCB6MG1zNcAiijzfMjDrY3K+W2CL+XeeJEO/c+HLF+Z hLXmb8bmvoelCk+CindZwXAuXDH14eYiDEVB94EV6xcInbDtAHygeEv1gLiLdTaXC Eo0SkFsAL/4g3UtXkQ== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from [192.168.31.113] ([46.125.249.97]) by mail.gmx.net (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MeCpb-1sQRnB3It5-00bKIV; Wed, 03 Apr 2024 10:24:34 +0200 Message-ID: <52a0cf2d-de88-4a83-aff5-3665bc2d3aae@HIDDEN> Date: Wed, 3 Apr 2024 10:24:34 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#69993: Wrap window buffers while cycling To: Juri Linkov <juri@HIDDEN> References: <86h6gug41x.fsf@HIDDEN> <3419df35-1b96-4a64-8ed7-722a05c58742@HIDDEN> <86le66ckhj.fsf@HIDDEN> <c2258795-4352-46af-85d3-0a4f1ba3d261@HIDDEN> <86h6gs2lk7.fsf@HIDDEN> <5c71ea64-0f97-4b90-af61-1156fe33f1ea@HIDDEN> <86cyreu78w.fsf@HIDDEN> <463c9242-56ef-4c99-9fe6-4b70be2071b2@HIDDEN> <86sf0abeg3.fsf@HIDDEN> <f3c9969f-64a0-491b-a5a8-7417a2cb9d45@HIDDEN> <86v855ggkv.fsf@HIDDEN> <91327e7b-d0a5-4f3a-a1f8-218d118608d6@HIDDEN> <86sf07bnl4.fsf@HIDDEN> <efd1b8d1-cec3-4e18-8aba-7fc2db9edaba@HIDDEN> <86v850jmmo.fsf@HIDDEN> <0d2fdebf-2149-4f92-89b8-45a8b6a7d272@HIDDEN> <86il10geth.fsf@HIDDEN> Content-Language: en-US From: martin rudalics <rudalics@HIDDEN> In-Reply-To: <86il10geth.fsf@HIDDEN> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:6XN2vvLx+lGHvQKdAQGpfjeDqC3FddKqSdo57j+ouHd3mrMsutp qrmgg/vi5ETvzLk0pxfdYa4Z+Kej8CEaUBmw/KiP63d4cZI1h9X07hQtJh3g7z5N+iJoF1f SW+uZuiSxShX60uIgCMnbm4Rvti8efXHr7AGzkClr60U/EkjWVbrrQPocpZHKwkA5mFOlXg 9ZhC4cfh1CTeE9TaLOyYA== X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:pU7zL6Ex8VU=;wfJ18a7E+YEqZZN1sa4JgBvmwK1 rhfpQg2eWubac42GlxP51kyJEm2Grkd2wE6AHfOCnOhSW04oSxlpWeOjFnhQCH3KOpdAJYUsT Ax43gU3elnGzpZtB5YLgO409Qe9IyJNHQSF6nyRElEa05KohioF2Kvl/RbfsR6ceX2U7/UZx9 rZF/PRsCSE+l08g6AWzvPz2NcquxetbAxvRIZwD2kPSBZAfyygIElmREeVo8fDGkkCmin38iI fed6VGy8x8OCYQzy6j0+f8cIAyHEWu2+9t6qDyKgCNa8KYO8PEBq6xoiajd+uiAcI6zqCeuq4 ncRU0XxTMsruqlzvuEDRLGFMRVLLQ0WpoZWHvCrTP1/h/s4/UapkJeCaPs66EDSvlSXJsSHwh oebywgHaUSaWKizxysWQtq5gVEyqd3BDr3KDV8y/8/O5nrGko/jragN9OVCfpQEzvHD3q/f8P v0sEBMAbj1ne8ja/ItTcT4P+7stD7F+LIdzlCFNIg9PrUZOVcJIG7U4tGRZ9IuchHnxvIwGH5 MgNZmY/UTHurGt/sgE6jmQcjhTgdJ7GGKKXyZuV0rO1zvFbVCPiQp/EBE12NGMmR7ByCuey+g KQKGqx4KAPXFRWfjRo7sYOlvBZl70NVE+wsnuKKoWlOI62/aB9w/cnfkhprnSLJu4OqqEL2uX DWIQwV/XBWiAo8JQgeRLajNbEyf0LOEE+Fm9STci/LGQKvHD/az6zYg12VuvuA9V9ZEeh2RB6 ec6VwNaY1OHNMAPgUYPYKlfkL36BzxKl9mCZfnOfQmXijr12ZuVUCayrqLBcj5WQ0vh4pr5hc IsVOI2QgoTxA2U+YmUfjIJeVSTjx4BiduFoUQLvxPrEdE= X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 69993 Cc: 69993 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.7 (-) >> 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. > > Indeed, this is why I asked to add a new hook after set-window-buffer, > like the hook record-window-buffer is called before set-window-buffer. Are you sure that 'window-buffer-change-functions' can't catch this already? IIUC all you need is to to know whether the current buffer of a window does not equal the value returned by 'window-old-buffer' for that window. martin
bug-gnu-emacs@HIDDEN:bug#69993; Package emacs.
Full text available.
Received: (at 69993) by debbugs.gnu.org; 3 Apr 2024 08:24:35 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Apr 03 04:24:34 2024
Received: from localhost ([127.0.0.1]:56983 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1rrvv7-0006E8-Qp
for submit <at> debbugs.gnu.org; Wed, 03 Apr 2024 04:24:34 -0400
Received: from mout.gmx.net ([212.227.17.22]:51753)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <rudalics@HIDDEN>) id 1rrvv4-0006DB-HV
for 69993 <at> debbugs.gnu.org; Wed, 03 Apr 2024 04:24:31 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.at;
s=s31663417; t=1712132659; x=1712737459; i=rudalics@HIDDEN;
bh=fp6C3aZd4Bgo8BirBhXVDPpHHJa4w52mrQSdlshe8B0=;
h=X-UI-Sender-Class:Date:Subject:To:Cc:References:From:
In-Reply-To;
b=dxvbd3ZRT4KY5R8q/EhEBfYfErKAUJaErYdjSY1SiCyiDtDmZl1AkWiDh1VA0Cyc
5l8M9fchLGDiJyA+XglRQcqvh4ceIf6z8brsQG7qUsgseO7XNY47jmb04fJ5h4EeI
smvV4MPIEtObEQPK3CMJf8lNM0qLpwGsjanpg/POyLi3pCwYQtYo7ZMfjaHCuCp0j
zRpziKOnRTUMgBFBiBG4ZbSHkOri+L1XcH/43cAFDhL/p57D2hgYsQZz7nQMM7Mq4
5IdPqthqD7mZr91T14K/wvKQTXcCB3Fyt5fIQj5Yed2+kNWJcurAgoOLKtbHxeIz1
Gk8qPgIB4NYqwhnnug==
X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a
Received: from [192.168.31.113] ([46.125.249.97]) by mail.gmx.net (mrgmx105
[212.227.17.168]) with ESMTPSA (Nemesis) id 1MCKFu-1s1JZJ1s5S-009NTH; Wed, 03
Apr 2024 10:24:19 +0200
Message-ID: <8a131d8b-1330-4d82-92f6-309f499e9c15@HIDDEN>
Date: Wed, 3 Apr 2024 10:24:18 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: bug#69993: Wrap window buffers while cycling
To: Juri Linkov <juri@HIDDEN>
References: <86h6gug41x.fsf@HIDDEN>
<3419df35-1b96-4a64-8ed7-722a05c58742@HIDDEN>
<86le66ckhj.fsf@HIDDEN>
<c2258795-4352-46af-85d3-0a4f1ba3d261@HIDDEN>
<86h6gs2lk7.fsf@HIDDEN>
<5c71ea64-0f97-4b90-af61-1156fe33f1ea@HIDDEN>
<86cyreu78w.fsf@HIDDEN>
<463c9242-56ef-4c99-9fe6-4b70be2071b2@HIDDEN>
<86sf0abeg3.fsf@HIDDEN>
<f3c9969f-64a0-491b-a5a8-7417a2cb9d45@HIDDEN>
<86v855ggkv.fsf@HIDDEN>
<91327e7b-d0a5-4f3a-a1f8-218d118608d6@HIDDEN>
<86sf07bnl4.fsf@HIDDEN>
<efd1b8d1-cec3-4e18-8aba-7fc2db9edaba@HIDDEN>
<86v850jmmo.fsf@HIDDEN>
<0d2fdebf-2149-4f92-89b8-45a8b6a7d272@HIDDEN>
<86plv8hz2v.fsf@HIDDEN>
Content-Language: en-US
From: martin rudalics <rudalics@HIDDEN>
In-Reply-To: <86plv8hz2v.fsf@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K1:PQYPsxCsT20oBenC1P/4J5gRSHid31mEkzFOEOLr80bWEUMhsKj
JkRStk5c8EDHngy02qpHeg1DgJydQ7gLjt32jFu+8MsxrWSEH0zGsd/sO5sNkRKPltXe4ZY
pP2PGqX133vM5F0ddYFt3F9jZxt/TXq2VzkFgonf6tasxjWHX4ewBkajI2eeV2M/0rcq9At
BCle1hn4mI85GcKuz9RCA==
X-Spam-Flag: NO
UI-OutboundReport: notjunk:1;M01:P0:V5sY5FCzews=;5nRMBNUI6qJHH4HJm1l1StD43dv
fSBhcTBnHHalJrPJG4OhQLaIqCsAb1BsaunxYdnijO/akNhE7NDTTeovoJ1TGJ0dLgtppw4jt
ajFu3MZCTxwNzr+0EruOYJRWbNnSCY6ivZMypqHyNgxIDqZ2yeAp7awGHFrPX8cNQSl6+ArBk
ElwchJ3Z84aICT3fGtrAUyUOFspz1e3TG4iesflHcCyPJbbq5qvIL1DfcjNvlhXFh0OrY9u5m
9ZszwCmVDj97F12/oojccBOhgk5zzCBKdWsuqcKzArMjA4vkX19R8663/hEyP1DzHGcSsnA+T
7vNkGHkxKARtUqwYk5dYTJBVwSSlmRwNZOTdLMlvrQ/rJ1QiKh47dJb2dhrBmh+dFOy7MkU4x
/VFqyk3Yj3M+SMvdieqijeODCQqwgDu/Yb76aGuEeqbSP2bQZ6x/gJU2+V81L7IXQJKyjq6um
oyjNoHRQZv5SWD91iujMCFIMU/Qujw0dzIMALEA87N6Iw+rHyjL/R6XiIeusTdR4ON/XL+0oh
f/S8HIV1xL/9RMJuk7w5OEU06qD96sjyvz5Uq7oi3HS3JuNn4wQHcBBN4Dfdaif5PsFqEdy+N
vEJ1MzSsvhbr0a2v+CVMVfhxpOshSpGsLlQH9HypzpAHf3oQsrERm5MOoGWaa+PRu1Is4MDAg
CwoIjVLcaq6urYNqJzfztdibD6FwDsFOZcPdqaGFOOuNe+c2zcrXAyEcTcdK/VVDI39VBKsvF
mQP62oVq66G3krxTXGDACRxkvugc9lzyH+I0VzGLl4NkwZhQ6M+qjrbqzZke8IcyVpncRn8we
KJAkA84KZquVECADNyebwCt+VrmBa6nDh/gUNhr+SvL2Q=
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 69993
Cc: 69993 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)
> Thanks, so the patch below ignores 'switch-to-prev-buffer-wrap' in
> 'switch-to-prev-buffer' when its argument BURY-OR-KILL is non-nil.
If I correctly caught your intentions, I'd rather write
(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."
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 ...
martin
bug-gnu-emacs@HIDDEN:bug#69993; Package emacs.
Full text available.
Received: (at 69993) by debbugs.gnu.org; 2 Apr 2024 16:49:39 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Apr 02 12:49:39 2024
Received: from localhost ([127.0.0.1]:56104 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1rrhKN-0002P2-7z
for submit <at> debbugs.gnu.org; Tue, 02 Apr 2024 12:49:39 -0400
Received: from relay1-d.mail.gandi.net ([2001:4b98:dc4:8::221]:53185)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <juri@HIDDEN>) id 1rrhKL-0002OG-7a
for 69993 <at> debbugs.gnu.org; Tue, 02 Apr 2024 12:49:37 -0400
Received: by mail.gandi.net (Postfix) with ESMTPSA id 1C0C6240005;
Tue, 2 Apr 2024 16:49:24 +0000 (UTC)
From: Juri Linkov <juri@HIDDEN>
To: martin rudalics <rudalics@HIDDEN>
Subject: Re: bug#69993: Wrap window buffers while cycling
In-Reply-To: <0d2fdebf-2149-4f92-89b8-45a8b6a7d272@HIDDEN> (martin rudalics's
message of "Tue, 2 Apr 2024 10:22:04 +0200")
Organization: LINKOV.NET
References: <86h6gug41x.fsf@HIDDEN>
<3419df35-1b96-4a64-8ed7-722a05c58742@HIDDEN>
<86le66ckhj.fsf@HIDDEN>
<c2258795-4352-46af-85d3-0a4f1ba3d261@HIDDEN>
<86h6gs2lk7.fsf@HIDDEN>
<5c71ea64-0f97-4b90-af61-1156fe33f1ea@HIDDEN>
<86cyreu78w.fsf@HIDDEN>
<463c9242-56ef-4c99-9fe6-4b70be2071b2@HIDDEN>
<86sf0abeg3.fsf@HIDDEN>
<f3c9969f-64a0-491b-a5a8-7417a2cb9d45@HIDDEN>
<86v855ggkv.fsf@HIDDEN>
<91327e7b-d0a5-4f3a-a1f8-218d118608d6@HIDDEN>
<86sf07bnl4.fsf@HIDDEN>
<efd1b8d1-cec3-4e18-8aba-7fc2db9edaba@HIDDEN>
<86v850jmmo.fsf@HIDDEN>
<0d2fdebf-2149-4f92-89b8-45a8b6a7d272@HIDDEN>
Date: Tue, 02 Apr 2024 19:40:44 +0300
Message-ID: <867chggdxj.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/30.0.50 (x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
X-GND-Sasl: juri@HIDDEN
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 69993
Cc: 69993 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)
--=-=-=
Content-Type: text/plain
>>> 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.
It's the same tab buffer that 'switch-to-prev-buffer' will switch to,
while using tab-line-tabs-window-buffers that is the default behavior.
So here are changes in the documentation that explain this:
--=-=-=
Content-Type: text/x-diff
Content-Disposition: inline; filename=tab-line-switch-cycling.patch
diff --git a/lisp/tab-line.el b/lisp/tab-line.el
index cc60f94c9c5..12414f0e06f 100644
--- a/lisp/tab-line.el
+++ b/lisp/tab-line.el
@@ -835,31 +849,48 @@
(switch-to-buffer buffer))))))
(defcustom tab-line-switch-cycling nil
- "Enable cycling tab switch.
+ "Wrap tabs on tab switch while cycling.
If non-nil, `tab-line-switch-to-prev-tab' in the first tab
switches to the last tab and `tab-line-switch-to-next-tab' in the
-last tab switches to the first tab. This variable is not consulted
-when `tab-line-tabs-function' is `tab-line-tabs-window-buffers'."
+last tab switches to the first tab.
+
+When `tab-line-tabs-function' is `tab-line-tabs-window-buffers',
+then you can customize `switch-to-prev-buffer-wrap' to t
+to achieve the same wrapping effect."
:type 'boolean
:group 'tab-line
:version "28.1")
(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])."
+When `tab-line-tabs-function' is `tab-line-tabs-window-buffers',
+its effect is the same as using the `previous-buffer' command
+\(\\[previous-buffer]). To wrap buffer cycling in this case,
+you can customize `switch-to-prev-buffer-wrap'.
+
+For other values of `tab-line-tabs-function' this command
+switches to the previous buffer in the sequence defined by
+`tab-line-tabs-function'. To wrap buffer cycling in this case,
+you can customize `tab-line-switch-cycling'."
(interactive (list last-nonmenu-event))
(let ((window (and (listp event) (posn-window (event-start event)))))
(if (eq tab-line-tabs-function #'tab-line-tabs-window-buffers)
@@ -835,31 +849,48 @@
(defun tab-line-switch-to-next-tab (&optional event)
"Switch to the next tab's buffer.
-Its effect is the same as using the `next-buffer' command
-(\\[next-buffer])."
+When `tab-line-tabs-function' is `tab-line-tabs-window-buffers',
+its effect is the same as using the `next-buffer' command
+\(\\[next-buffer]). To wrap buffer cycling in this case,
+you can customize `switch-to-prev-buffer-wrap'.
+
+For other values of `tab-line-tabs-function' this command
+switches to the next buffer in the sequence defined by
+`tab-line-tabs-function'. To wrap buffer cycling in this case,
+you can customize `tab-line-switch-cycling'."
(interactive (list last-nonmenu-event))
(let ((window (and (listp event) (posn-window (event-start event)))))
(if (eq tab-line-tabs-function #'tab-line-tabs-window-buffers)
(switch-to-next-buffer window)
(with-selected-window (or window (selected-window))
--=-=-=--
bug-gnu-emacs@HIDDEN:bug#69993; Package emacs.
Full text available.
Received: (at 69993) by debbugs.gnu.org; 2 Apr 2024 16:49:38 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Apr 02 12:49:38 2024
Received: from localhost ([127.0.0.1]:56102 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1rrhKL-0002Op-Sq
for submit <at> debbugs.gnu.org; Tue, 02 Apr 2024 12:49:38 -0400
Received: from relay8-d.mail.gandi.net ([217.70.183.201]:39879)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <juri@HIDDEN>) id 1rrhKH-0002Ny-HZ
for 69993 <at> debbugs.gnu.org; Tue, 02 Apr 2024 12:49:34 -0400
Received: by mail.gandi.net (Postfix) with ESMTPSA id C79291BF206;
Tue, 2 Apr 2024 16:49:22 +0000 (UTC)
From: Juri Linkov <juri@HIDDEN>
To: martin rudalics <rudalics@HIDDEN>
Subject: Re: bug#69993: Wrap window buffers while cycling
In-Reply-To: <0d2fdebf-2149-4f92-89b8-45a8b6a7d272@HIDDEN> (martin rudalics's
message of "Tue, 2 Apr 2024 10:22:04 +0200")
Organization: LINKOV.NET
References: <86h6gug41x.fsf@HIDDEN>
<3419df35-1b96-4a64-8ed7-722a05c58742@HIDDEN>
<86le66ckhj.fsf@HIDDEN>
<c2258795-4352-46af-85d3-0a4f1ba3d261@HIDDEN>
<86h6gs2lk7.fsf@HIDDEN>
<5c71ea64-0f97-4b90-af61-1156fe33f1ea@HIDDEN>
<86cyreu78w.fsf@HIDDEN>
<463c9242-56ef-4c99-9fe6-4b70be2071b2@HIDDEN>
<86sf0abeg3.fsf@HIDDEN>
<f3c9969f-64a0-491b-a5a8-7417a2cb9d45@HIDDEN>
<86v855ggkv.fsf@HIDDEN>
<91327e7b-d0a5-4f3a-a1f8-218d118608d6@HIDDEN>
<86sf07bnl4.fsf@HIDDEN>
<efd1b8d1-cec3-4e18-8aba-7fc2db9edaba@HIDDEN>
<86v850jmmo.fsf@HIDDEN>
<0d2fdebf-2149-4f92-89b8-45a8b6a7d272@HIDDEN>
Date: Tue, 02 Apr 2024 19:34:43 +0300
Message-ID: <86il10geth.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/30.0.50 (x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain
X-GND-Sasl: juri@HIDDEN
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 69993
Cc: 69993 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)
>> '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.
You can also see how 'tab-line-select-tab-buffer' emulates
'switch-to-buffer' to keep the fixed order by using
'switch-to-prev-buffer':
((and (eq tab-line-tabs-function #'tab-line-tabs-window-buffers)
(memq buffer prev-buffers))
(dotimes (_ (1+ (seq-position prev-buffers buffer)))
(switch-to-prev-buffer 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.
Indeed, this is why I asked to add a new hook after set-window-buffer,
like the hook record-window-buffer is called before set-window-buffer.
Then 'tab-line-select-tab-buffer' will just let-bind a new variable
like 'switch-to-prev-buffer-wrap' that will keep the fixed order
with a hook above, and use 'set-window-buffer'.
> Think only of 'switch-to-buffer-obey-display-actions'.
Thanks for reminding about 'switch-to-buffer-obey-display-actions'.
This means that all uses of 'switch-to-buffer' in tab-line.el are wrong
and should be replaced with 'set-window-buffer'.
Or 'switch-to-buffer' still does necessary things?
Then maybe better to wrap 'switch-to-buffer' calls with
(let ((switch-to-buffer-obey-display-actions nil))
(switch-to-buffer buffer))
bug-gnu-emacs@HIDDEN:bug#69993; Package emacs.
Full text available.
Received: (at 69993) by debbugs.gnu.org; 2 Apr 2024 16:49:34 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Apr 02 12:49:34 2024
Received: from localhost ([127.0.0.1]:56099 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1rrhKI-0002Od-6W
for submit <at> debbugs.gnu.org; Tue, 02 Apr 2024 12:49:34 -0400
Received: from relay6-d.mail.gandi.net ([217.70.183.198]:46069)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <juri@HIDDEN>) id 1rrhKF-0002Nv-Mc
for 69993 <at> debbugs.gnu.org; Tue, 02 Apr 2024 12:49:33 -0400
Received: by mail.gandi.net (Postfix) with ESMTPSA id 3F837C0003;
Tue, 2 Apr 2024 16:49:19 +0000 (UTC)
From: Juri Linkov <juri@HIDDEN>
To: martin rudalics <rudalics@HIDDEN>
Subject: Re: bug#69993: Wrap window buffers while cycling
In-Reply-To: <0d2fdebf-2149-4f92-89b8-45a8b6a7d272@HIDDEN> (martin rudalics's
message of "Tue, 2 Apr 2024 10:22:04 +0200")
Organization: LINKOV.NET
References: <86h6gug41x.fsf@HIDDEN>
<3419df35-1b96-4a64-8ed7-722a05c58742@HIDDEN>
<86le66ckhj.fsf@HIDDEN>
<c2258795-4352-46af-85d3-0a4f1ba3d261@HIDDEN>
<86h6gs2lk7.fsf@HIDDEN>
<5c71ea64-0f97-4b90-af61-1156fe33f1ea@HIDDEN>
<86cyreu78w.fsf@HIDDEN>
<463c9242-56ef-4c99-9fe6-4b70be2071b2@HIDDEN>
<86sf0abeg3.fsf@HIDDEN>
<f3c9969f-64a0-491b-a5a8-7417a2cb9d45@HIDDEN>
<86v855ggkv.fsf@HIDDEN>
<91327e7b-d0a5-4f3a-a1f8-218d118608d6@HIDDEN>
<86sf07bnl4.fsf@HIDDEN>
<efd1b8d1-cec3-4e18-8aba-7fc2db9edaba@HIDDEN>
<86v850jmmo.fsf@HIDDEN>
<0d2fdebf-2149-4f92-89b8-45a8b6a7d272@HIDDEN>
Date: Tue, 02 Apr 2024 19:28:32 +0300
Message-ID: <86plv8hz2v.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/30.0.50 (x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
X-GND-Sasl: juri@HIDDEN
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 69993
Cc: 69993 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)
--=-=-=
Content-Type: text/plain
>> 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?
Thanks, so the patch below ignores 'switch-to-prev-buffer-wrap' in
'switch-to-prev-buffer' when its argument BURY-OR-KILL is non-nil.
--=-=-=
Content-Type: text/x-diff
Content-Disposition: inline; filename=switch-to-prev-buffer-wrap.patch
diff --git a/lisp/window.el b/lisp/window.el
index df55a7ca673..f1486b15e0a 100644
--- a/lisp/window.el
+++ b/lisp/window.el
@@ -4542,6 +4542,22 @@ set-window-buffer-start-and-point
(when point
(set-window-point window point))))
+(defcustom switch-to-prev-buffer-wrap nil
+ "Wrap to the first or last window buffer while cycling.
+The value t means wrapping around while cycling buffers appeared in the
+window before. So when the commands that switch buffers in the selected
+window `previous-buffer' and `next-buffer' reach the first or the last
+buffer (these buffers are visible when using `tab-line-mode'),
+then wrap around to another end of the list of previous/next buffers.
+
+When the value is `stop', stop at the first or last buffer
+in the list of previous/next buffers, but don't wrap around."
+ :type '(choice (const :tag "Never wrap" nil)
+ (const :tag "Stop at window-local buffers" stop)
+ (const :tag "Wrap to window-local buffers" t))
+ :version "30.1"
+ :group 'windows)
+
(defcustom switch-to-visible-buffer t
"If non-nil, allow switching to an already visible buffer.
If this variable is non-nil, `switch-to-prev-buffer' and
@@ -4676,7 +4692,8 @@ switch-to-prev-buffer
((or switch-to-prev-buffer-skip
(not switch-to-visible-buffer))
frame)))
- entry new-buffer killed-buffers skipped)
+ (wrap (and switch-to-prev-buffer-wrap (not bury-or-kill)))
+ entry new-buffer killed-buffers skipped wrapped)
(when (window-minibuffer-p window)
;; Don't switch in minibuffer window.
(unless (setq window (minibuffer-selected-window))
@@ -4710,8 +4727,8 @@ switch-to-prev-buffer
;; a buried buffer instead. Otherwise, we must reverse the global
;; buffer list in order to make sure that switching to the
;; previous/next buffer traverse it in opposite directions. Skip
- ;; this step for side windows.
- (unless window-side
+ ;; this step for side windows or when wrapping.
+ (unless (or window-side wrap)
(dolist (buffer (if bury-or-kill
(buffer-list frame)
(nreverse (buffer-list frame))))
@@ -4729,7 +4746,8 @@ switch-to-prev-buffer
(set-window-buffer-start-and-point window new-buffer)
(throw 'found t)))))
- (unless bury-or-kill
+ (when (eq wrap 'stop) (setq wrapped 'stop))
+ (unless (or bury-or-kill (eq wrap 'stop))
;; Scan reverted next buffers last (must not use nreverse
;; here!).
(dolist (buffer (reverse next-buffers))
@@ -4743,12 +4761,13 @@ switch-to-prev-buffer
(setq entry (assq buffer (window-prev-buffers window))))
(if (switch-to-prev-buffer-skip-p skip window buffer bury-or-kill)
(setq skipped (or skipped buffer))
- (setq new-buffer buffer)
+ (setq new-buffer buffer wrapped t)
(set-window-buffer-start-and-point
window new-buffer (nth 1 entry) (nth 2 entry))
(throw 'found t)))))
- (when (and skipped (not (functionp switch-to-prev-buffer-skip)))
+ (when (and skipped (not (functionp switch-to-prev-buffer-skip))
+ (not wrapped))
;; Show first skipped buffer, unless skip was a function.
(setq new-buffer skipped)
(set-window-buffer-start-and-point window new-buffer)))
@@ -4768,10 +4787,28 @@ switch-to-prev-buffer
;; it.
(set-window-prev-buffers
window (append (window-prev-buffers window) (list entry)))))
- ;; Move `old-buffer' to head of WINDOW's restored list of next
- ;; buffers.
- (set-window-next-buffers
- window (cons old-buffer (delq old-buffer next-buffers))))
+ (if (not (and wrap wrapped))
+ ;; Move `old-buffer' to head of WINDOW's restored list of next
+ ;; buffers.
+ (set-window-next-buffers
+ window (cons old-buffer (delq old-buffer next-buffers)))
+ (if (eq wrapped 'stop)
+ (setq new-buffer nil)
+ ;; Restore the right order of previous buffers.
+ (let ((prev-buffers (window-prev-buffers window)))
+ ;; Use the same sorting order as was in next-buffers
+ ;; with old-buffer at the bottom.
+ (setq prev-buffers
+ (sort prev-buffers
+ (lambda (a b)
+ (cond
+ ((eq (car a) old-buffer) nil)
+ ((eq (car b) old-buffer) t)
+ (t (< (length (memq (car a) next-buffers))
+ (length (memq (car b) next-buffers))))))))
+ (set-window-prev-buffers window prev-buffers)
+ ;; When record-window-buffer doesn't reset next-buffers.
+ (set-window-next-buffers window nil)))))
;; Remove killed buffers from WINDOW's previous and next buffers.
(when killed-buffers
@@ -4812,7 +4849,8 @@ switch-to-next-buffer
((or switch-to-prev-buffer-skip
(not switch-to-visible-buffer))
frame)))
- new-buffer entry killed-buffers skipped)
+ (wrap switch-to-prev-buffer-wrap)
+ new-buffer entry killed-buffers skipped wrapped)
(when (window-minibuffer-p window)
;; Don't switch in minibuffer window.
(unless (setq window (minibuffer-selected-window))
@@ -4839,7 +4877,7 @@ switch-to-next-buffer
(throw 'found t))))
;; Scan the buffer list of WINDOW's frame next, skipping previous
;; buffers entries. Skip this step for side windows.
- (unless window-side
+ (unless (or window-side wrap)
(dolist (buffer (buffer-list frame))
(when (and (buffer-live-p buffer)
(not (eq buffer old-buffer))
@@ -4856,27 +4894,37 @@ switch-to-next-buffer
(throw 'found t)))))
;; Scan WINDOW's reverted previous buffers last (must not use
;; nreverse here!)
- (dolist (entry (reverse (window-prev-buffers window)))
- (when (and (not (eq new-buffer (car entry)))
- (not (eq old-buffer (car entry)))
- (setq new-buffer (car entry))
- (or (buffer-live-p new-buffer)
- (not (setq killed-buffers
- (cons new-buffer killed-buffers))))
- (or (null pred) (funcall pred new-buffer)))
- (if (switch-to-prev-buffer-skip-p skip window new-buffer)
- (setq skipped (or skipped new-buffer))
- (set-window-buffer-start-and-point
- window new-buffer (nth 1 entry) (nth 2 entry))
- (throw 'found t))))
+ (if (eq wrap 'stop) (setq wrapped 'stop)
+ (dolist (entry (reverse (window-prev-buffers window)))
+ (when (and (not (eq new-buffer (car entry)))
+ (not (eq old-buffer (car entry)))
+ (setq new-buffer (car entry))
+ (or (buffer-live-p new-buffer)
+ (not (setq killed-buffers
+ (cons new-buffer killed-buffers))))
+ (or (null pred) (funcall pred new-buffer)))
+ (if (switch-to-prev-buffer-skip-p skip window new-buffer)
+ (setq skipped (or skipped new-buffer))
+ (setq wrapped t)
+ (set-window-buffer-start-and-point
+ window new-buffer (nth 1 entry) (nth 2 entry))
+ (throw 'found t)))))
- (when (and skipped (not (functionp switch-to-prev-buffer-skip)))
+ (when (and skipped (not (functionp switch-to-prev-buffer-skip))
+ (not wrapped))
;; Show first skipped buffer, unless skip was a function.
(setq new-buffer skipped)
(set-window-buffer-start-and-point window new-buffer)))
- ;; Remove `new-buffer' from and restore WINDOW's next buffers.
- (set-window-next-buffers window (delq new-buffer next-buffers))
+ (if (not (and wrap wrapped))
+ ;; Remove `new-buffer' from and restore WINDOW's next buffers.
+ (set-window-next-buffers window (delq new-buffer next-buffers))
+ (if (eq wrapped 'stop)
+ (setq new-buffer nil)
+ (let ((prev-buffers (window-prev-buffers window)))
+ (setq prev-buffers
+ (nreverse (delq new-buffer (mapcar #'car prev-buffers))))
+ (set-window-next-buffers window prev-buffers))))
;; Remove killed buffers from WINDOW's previous and next buffers.
(when killed-buffers
--=-=-=--
bug-gnu-emacs@HIDDEN:bug#69993; Package emacs.
Full text available.
Received: (at 69993) by debbugs.gnu.org; 2 Apr 2024 08:22:22 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Apr 02 04:22:21 2024
Received: from localhost ([127.0.0.1]:52231 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1rrZPQ-0007qi-3m
for submit <at> debbugs.gnu.org; Tue, 02 Apr 2024 04:22:21 -0400
Received: from mout.gmx.net ([212.227.15.19]:49615)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <rudalics@HIDDEN>) id 1rrZPL-0007pa-4t
for 69993 <at> debbugs.gnu.org; Tue, 02 Apr 2024 04:22:18 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.at;
s=s31663417; t=1712046124; x=1712650924; i=rudalics@HIDDEN;
bh=EZ4qocgxDqf4BZqmpFxKCxM8XAQgtpQKvpSE06iCW+Y=;
h=X-UI-Sender-Class:Date:Subject:To:Cc:References:From:
In-Reply-To;
b=rnrxG4TmnEoezshTuS0/QfvieuvVJmHYn0/3gFl4w2Y4pJwwgxrpWrBNzZLw/frW
C+snexqRJ9oDboqFoMgAsotH/bj4tGtgkQC3/uhAk9ZMeZPZ/kIJmsdKsBibHJeUB
3rmzwGXOb49/csks7fMP1VGcsEbxg4CXm6hAe6oD17vSpfeu3ImXsWFsrtcOU3p5M
cgDBFxDjItf06FICI3cOL3mVR35kUszuqrtUKLKNgqd1SDHzNTITW75zISOW8ffCk
lQOyMU6iEBbMoirUP4I4Pk81T1tEL2rGVhTXF6Ap18HiOHqCWj7zzu5cDuHXxFrVX
kkhVplKwXyU74R16NA==
X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a
Received: from [192.168.31.113] ([46.125.249.85]) by mail.gmx.net (mrgmx005
[212.227.17.190]) with ESMTPSA (Nemesis) id 1Mxm3Q-1skwXy2yjO-00zFtY; Tue, 02
Apr 2024 10:22:04 +0200
Message-ID: <0d2fdebf-2149-4f92-89b8-45a8b6a7d272@HIDDEN>
Date: Tue, 2 Apr 2024 10:22:04 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: bug#69993: Wrap window buffers while cycling
To: Juri Linkov <juri@HIDDEN>
References: <86h6gug41x.fsf@HIDDEN>
<3419df35-1b96-4a64-8ed7-722a05c58742@HIDDEN>
<86le66ckhj.fsf@HIDDEN>
<c2258795-4352-46af-85d3-0a4f1ba3d261@HIDDEN>
<86h6gs2lk7.fsf@HIDDEN>
<5c71ea64-0f97-4b90-af61-1156fe33f1ea@HIDDEN>
<86cyreu78w.fsf@HIDDEN>
<463c9242-56ef-4c99-9fe6-4b70be2071b2@HIDDEN>
<86sf0abeg3.fsf@HIDDEN>
<f3c9969f-64a0-491b-a5a8-7417a2cb9d45@HIDDEN>
<86v855ggkv.fsf@HIDDEN>
<91327e7b-d0a5-4f3a-a1f8-218d118608d6@HIDDEN>
<86sf07bnl4.fsf@HIDDEN>
<efd1b8d1-cec3-4e18-8aba-7fc2db9edaba@HIDDEN>
<86v850jmmo.fsf@HIDDEN>
Content-Language: en-US
From: martin rudalics <rudalics@HIDDEN>
In-Reply-To: <86v850jmmo.fsf@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: base64
X-Provags-ID: V03:K1:R+QivnfWq8YQ1JP7hUEk3dWu9nImNCrIdvFaRF9aceediJ/G1It
4gGqVH1iXskMGGomK3ywWc595kNIsIcSPZ33ZkKeruhka9ILY5XRXsuMSSNQLRZlb9dmdZW
WuDyf1kSLo1CQmZyl/upbO2hw+gplyZBBpqKhJik4pW2a7CuSyLTeV3dClLHOsT7WbNeSrK
5sua7Q+gcJbAIPL0Yfrxw==
X-Spam-Flag: NO
UI-OutboundReport: notjunk:1;M01:P0:luy2FyqZ0Ow=;hIXgCzw/yvZ+DqEYnQznZanRw2z
F/JdX3Ou/fTZAulp5vVQWmc04f63dElTfHbLoytl074yKu/THpP+NMJl2RPz2gog5ZA+HqUIl
avXjH8yANfIf2uuPQ/HSclk8CxxAXZ0+a2Qqa/gPZ7j2bY2csi15+Q5wk3mpu828e4X4OyuIP
R/D7bkM3shNOJRYBkFaAGpz6i5F09NUns8u+dR356O+/xhxLHexco6nt8n61lhbw46VA7A4zx
QP9wuLSHx0KhkS7Bp3Q8xXnN8FnsbvvKy736ZmlLMaZQwCJsq1eVRRn8J3sum4ZVeZixkadP5
LDWYAR5pdvSUIoHTFXBI/qKs+SokVKaDJ6WRJOeM42P5xWlr0uxLhNW0JUZDoxuvTzU+4vFhg
xtMqwJrfkGedD9X88kS9U4x7N71WS1/2YpEkr36Y3rw3xGfiMqC2qNnRrxrxdHVU+Ubk2jSb9
sus1XWLTy6pAKV/sf7R+6G9qf1Aj/QmboH4Egzfn4OkObIuAOeh7u6nYc/jFLBMLO57m9QAkh
5hjIHUuRU2K9G3tTUA2+uYoloaVUMQI/AUbGu07qVjmt0t2YOUGD2or8VIUL13GqLJU89ZEnv
gKBQi6JSWMD+dfAcfhaRG4CTXiZINOR9WwhlJ2UW4sgHu1lqTgH+GEetmJjzg5jUpMUmXm3Co
P8hpEidFa7/K6FWmFWPINaR8BPcPhWgTwpMtOm6TBwN9GE3dGH9eCLW+T+/I+8OvyXu7N3M5a
QBkpxZTTSaeQTAbOb8zn0EEuxPWcl4HddaLlg5PB/GbgorisxyfWQMvcsd/3TjAg+6mNXUKHn
uag3/nzZ6Jne+/2XRWXTEHbpi4Gx+X74xjzrgPyB6no5A=
X-Spam-Score: 2.8 (++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
has NOT identified this incoming email as spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
the administrator of that system for details.
Content preview: > 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 [...]
Content analysis details: (2.8 points, 10.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
3.6 RCVD_IN_SBL_CSS RBL: Received via a relay in Spamhaus SBL-CSS
[46.125.249.85 listed in zen.spamhaus.org]
-0.0 SPF_PASS SPF: sender matches SPF record
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail
provider (rudalics[at]gmx.at)
0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record
-0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at https://www.dnswl.org/,
low trust
[212.227.15.19 listed in list.dnswl.org]
-0.0 RCVD_IN_MSPIKE_H3 RBL: Good reputation (+3)
[212.227.15.19 listed in wl.mailspike.net]
-0.0 RCVD_IN_MSPIKE_WL Mailspike good senders
X-Debbugs-Envelope-To: 69993
Cc: 69993 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 1.8 (+)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
has NOT identified this incoming email as spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
the administrator of that system for details.
Content preview: > 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 [...]
Content analysis details: (1.8 points, 10.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
-0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at https://www.dnswl.org/,
low trust
[212.227.15.19 listed in list.dnswl.org]
3.6 RCVD_IN_SBL_CSS RBL: Received via a relay in Spamhaus SBL-CSS
[46.125.249.85 listed in zen.spamhaus.org]
-0.0 RCVD_IN_MSPIKE_H3 RBL: Good reputation (+3)
[212.227.15.19 listed in wl.mailspike.net]
-0.0 SPF_PASS SPF: sender matches SPF record
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail
provider (rudalics[at]gmx.at)
0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record
-0.0 RCVD_IN_MSPIKE_WL Mailspike good senders
-1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list
manager
ID4gSSBzZWUgdGhhdCB0aGUgRWxpc3AgbWFudWFsIGFsc28gc2F5cyBhYm91dCAnc3dpdGNo
LXRvLXByZXYtYnVmZmVyJzoNCiA+DQogPiAgIC0tIENvbW1hbmQ6IGJ1cnktYnVmZmVyICZv
cHRpb25hbCBidWZmZXItb3ItbmFtZQ0KID4gICAgICAgLi4uDQogPiAgICAgICAoKm5vdGUg
UXVpdHRpbmcgV2luZG93czo6KS4gIE90aGVyd2lzZSwgaXQgY2FsbHMNCiA+ICAgICAgIOKA
mHN3aXRjaC10by1wcmV2LWJ1ZmZlcuKAmSAoKm5vdGUgV2luZG93IEhpc3Rvcnk6OikNCiA+
ICAgICAgIHRvIHNob3cgYW5vdGhlciBidWZmZXIgaW4gdGhhdCB3aW5kb3cuDQogPg0KID4g
VGhpcyBtZWFucyB0aGF0IGl0IHJldXNlcyBzd2l0Y2gtdG8tcHJldi1idWZmZXIgdG8gc2hv
dyBhbnkgYXZhaWxhYmxlDQogPiBidWZmZXIsIGV2ZW4gdGhlIGJ1ZmZlcnMgdGhhdCB3ZXJl
IG5ldmVyIHNob3duIGluIHRoYXQgd2luZG93Lg0KDQpFdmVuIGJ1ZmZlcnMgdGhhdCB3ZXJl
IG5ldmVyIHNob3duIGFueXdoZXJlLiAgVGhhdCdzIHRoZSB3YXkgRW1hY3MNCnRyYWRpdGlv
bmFsbHkgYmVoYXZlcyBhbmQgd2UgYXJlIG5vdCBzdXBwb3NlZCB0byBjaGFuZ2UgdGhhdC4N
Cg0KID4gVGhpcyBtZWFucyB0aGF0IHN1Y2ggY2FsbHMgc2hvdWxkIGJlIHdyYXBwZWQgd2l0
aCBsZXQtYmluZA0KID4gdG8gaGFuZGxlIHRoZSBjYXNlIHdoZW4gdGhlIGxpc3Qgb2YgcHJl
di9uZXh0LWJ1ZmZlcnMgYmVjb21lcyBlbXB0eQ0KID4gdG8gc3dpdGNoIHRvIGFueSBvdGhl
ciBidWZmZXIgbm90IHNob3duIGluIHRoYXQgd2luZG93IGJlZm9yZToNCiA+DQogPiBAQCAt
NDk5NCw3ICs1MDQyLDggQEAgYnVyeS1idWZmZXINCiA+ICAgICAgICAodA0KID4gICAgICAg
ICA7OyBTd2l0Y2ggdG8gYW5vdGhlciBidWZmZXIgaW4gd2luZG93Lg0KID4gICAgICAgICAo
c2V0LXdpbmRvdy1kZWRpY2F0ZWQtcCBuaWwgbmlsKQ0KID4gLSAgICAgIChzd2l0Y2gtdG8t
cHJldi1idWZmZXIgbmlsICdidXJ5KSkpDQogPiArICAgICAgKGxldCAoKHN3aXRjaC10by1w
cmV2LWJ1ZmZlci13cmFwIG5pbCkpDQogPiArICAgICAgICAoc3dpdGNoLXRvLXByZXYtYnVm
ZmVyIG5pbCAnYnVyeSkpKSkNCiA+ICAgICAgIDs7IEFsd2F5cyByZXR1cm4gbmlsLg0KID4g
ICAgICAgbmlsKSkNCg0KWW91IG1lYW4gdG8gYXZvaWQgYSAiQ291bGQgbm90IHJlcGxhY2Ug
YnVmZmVyIC4uLiIgZXJyb3I/ICBDYW4ndCB3ZQ0KaGFuZGxlIHRoaXMgcHJvYmxlbSBpbiAn
c3dpdGNoLXRvLXByZXYtYnVmZmVyJyB3aGVuIEJVUlktT1ItS0lMTCBhbmQNCidzd2l0Y2gt
dG8tcHJldi1idWZmZXItd3JhcCcgYXJlIG5vbi1uaWwsIGhlcmUgYW5kIGluIHRoZSBvdGhl
ciBjYWxscw0KeW91IGNpdGU/DQoNCiA+ICdDLXggYicgaXMgbm90IGRpZmZlcmVudCBmcm9t
ICdDLXggPGxlZnQ+JyBhbmQgJ0MteCA8cmlnaHQ+Jw0KID4gd2hlbiB0aGUgYnVmZmVyIHNl
bGVjdGVkIGZvciAnQy14IGInIHdhcyBhbHJlYWR5IHNob3duIGluIHRoZSB3aW5kb3cuDQoN
CkJ1dCB0aGVuIHdlIHdvdWxkIGhhdmUgdG8gaGFuZGxlIGFueSBjYWxsIG9mIHNldF93aW5k
b3dfYnVmZmVyIHRoYXQNCnJlcGxhY2VzIGEgd2luZG93J3MgYnVmZmVyIHdpdGggb25lIHRo
YXQgaGFzIGJlZW4gcHJldmlvdXNseSBzaG93biBpbg0KdGhhdCB3aW5kb3cuICBUaGluayBv
bmx5IG9mICdzd2l0Y2gtdG8tYnVmZmVyLW9iZXktZGlzcGxheS1hY3Rpb25zJy4NCg0KID4+
IEkgdGhpbmsgdGhlIGZvbGxvd2luZyBpcyBwcm9ibGVtYXRpYzoNCiA+Pg0KID4+ICAgIChk
ZWZ1biB0YWItbGluZS1zd2l0Y2gtdG8tcHJldi10YWIgKCZvcHRpb25hbCBldmVudCkNCiA+
PiAgICAgICJTd2l0Y2ggdG8gdGhlIHByZXZpb3VzIHRhYidzIGJ1ZmZlci4NCiA+PiAgICBJ
dHMgZWZmZWN0IGlzIHRoZSBzYW1lIGFzIHVzaW5nIHRoZSBgcHJldmlvdXMtYnVmZmVyJyBj
b21tYW5kDQogPj4gICAgKFxcW3ByZXZpb3VzLWJ1ZmZlcl0pLiINCiA+Pg0KID4+IElmIHRo
ZSAicHJldmlvdXMgdGFiIiBkb2VzIG5vdCBzaG93IHRoZSBidWZmZXIgJ3N3aXRjaC10by1w
cmV2LWJ1ZmZlcicNCiA+PiB3b3VsZCBzd2l0Y2ggdG8sIHRoZW4gdGhlIGRvYyBpcyB3cm9u
Zy4gIEknbSBub3Qgc3VyZSB3aGV0aGVyDQogPj4gJ3RhYi1saW5lLXRhYnMtd2luZG93LWJ1
ZmZlcnMnIGNhbiBndWFyYW50ZWUgdGhhdCB0aGlzIGNob29zZXMgdGhlIHNhbWUNCiA+PiBi
dWZmZXIgJ3N3aXRjaC10by1wcmV2LWJ1ZmZlcicgd291bGQgc3dpdGNoIHRvLCB0aG91Z2gu
ICBJZiBpdCBkb2Vzbid0LA0KID4+IHRoZW4gdGhlIGVmZmVjdCBzaG91bGQgYmUgdGhhdCBv
ZiBDLXggYiBzd2l0Y2hpbmcgdG8gYSBidWZmZXIgZWFybGllcg0KID4+IHNob3duIGluIHRo
YXQgd2luZG93LiAgQlRXLCBidXJ5aW5nIGEgYnVmZmVyIHJlbW92ZXMgaXQgZnJvbSB0aGUg
dGFiDQogPj4gbGluZSBidXQgZG9lcyBub3QgcHJldmVudCAnc3dpdGNoLXRvLXByZXYtYnVm
ZmVyJyBmcm9tIHN3aXRjaGluZyB0byBpdCAtDQogPj4gaXQganVzdCBtYWtlcyBpdCB2ZXJ5
IHVubGlrZWx5IElJUkMuDQogPg0KID4gdGFiLWxpbmUtc3dpdGNoLXRvLXByZXYtdGFiIGRv
ZXNuJ3QgY2hvb3NlIGJ1ZmZlcnMgaXRzZWxmOg0KID4gZm9yIHRhYi1saW5lLXRhYnMtd2lu
ZG93LWJ1ZmZlcnMgaXQganVzdCBkZWxlZ2F0ZXMgdGhlIHRhc2sNCiA+IHRvIHN3aXRjaC10
by1wcmV2LWJ1ZmZlci4NCg0KQnV0IHdoYXQgaXMgdGhlICJwcmV2aW91cyB0YWIiPyAgSUlV
QyBpdCBpcyB0aGUgb25lIG9uIHRoZSBsZWZ0IG9mIHRoZQ0KY3VycmVudCB0YWIgaW4gdGhl
IHRhYiBsaW5lLiAgQnV0IHRoYXQgdGFiIGlzIG5vdCBuZWNlc3NhcmlseSB0aGUgb25lDQon
c3dpdGNoLXRvLXByZXYtYnVmZmVyJyB3aWxsIHN3aXRjaCB0by4NCg0KbWFydGluDQo=
bug-gnu-emacs@HIDDEN:bug#69993; Package emacs.
Full text available.
Received: (at 69993) by debbugs.gnu.org; 2 Apr 2024 06:41:17 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Apr 02 02:41:17 2024
Received: from localhost ([127.0.0.1]:52137 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1rrXpc-0008A6-Be
for submit <at> debbugs.gnu.org; Tue, 02 Apr 2024 02:41:17 -0400
Received: from relay9-d.mail.gandi.net ([2001:4b98:dc4:8::229]:35193)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <juri@HIDDEN>) id 1rrXpX-00088W-Iu
for 69993 <at> debbugs.gnu.org; Tue, 02 Apr 2024 02:41:14 -0400
Received: by mail.gandi.net (Postfix) with ESMTPSA id 81603FF806;
Tue, 2 Apr 2024 06:41:00 +0000 (UTC)
From: Juri Linkov <juri@HIDDEN>
To: martin rudalics <rudalics@HIDDEN>
Subject: Re: bug#69993: Wrap window buffers while cycling
In-Reply-To: <efd1b8d1-cec3-4e18-8aba-7fc2db9edaba@HIDDEN> (martin rudalics's
message of "Sun, 31 Mar 2024 10:32:30 +0200")
Organization: LINKOV.NET
References: <86h6gug41x.fsf@HIDDEN>
<3419df35-1b96-4a64-8ed7-722a05c58742@HIDDEN>
<86le66ckhj.fsf@HIDDEN>
<c2258795-4352-46af-85d3-0a4f1ba3d261@HIDDEN>
<86h6gs2lk7.fsf@HIDDEN>
<5c71ea64-0f97-4b90-af61-1156fe33f1ea@HIDDEN>
<86cyreu78w.fsf@HIDDEN>
<463c9242-56ef-4c99-9fe6-4b70be2071b2@HIDDEN>
<86sf0abeg3.fsf@HIDDEN>
<f3c9969f-64a0-491b-a5a8-7417a2cb9d45@HIDDEN>
<86v855ggkv.fsf@HIDDEN>
<91327e7b-d0a5-4f3a-a1f8-218d118608d6@HIDDEN>
<86sf07bnl4.fsf@HIDDEN>
<efd1b8d1-cec3-4e18-8aba-7fc2db9edaba@HIDDEN>
Date: Tue, 02 Apr 2024 09:37:36 +0300
Message-ID: <86v850jmmo.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/30.0.50 (x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-GND-Sasl: juri@HIDDEN
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 69993
Cc: 69993 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)
> The Elisp manual says about 'switch-to-prev-buffer'
>
> The previous buffer is usually the buffer shown before the buffer
> currently shown in WINDOW. However, a buffer that has been buried
> or killed, or has been already shown by a recent invocation of
> ‘switch-to-prev-buffer’, does not qualify as previous buffer.
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.
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))
Also for:
-- Command: replace-buffer-in-windows &optional buffer-or-name
...
The replacement buffer in each window is chosen via
‘switch-to-prev-buffer’ (*note Window History::).
need the same:
@@ -5145,7 +5194,8 @@ replace-buffer-in-windows
(when (or dedicated-side (not (window--delete window t t)))
;; Switch to another buffer in that window.
(set-window-dedicated-p window nil)
- (if (switch-to-prev-buffer window 'kill)
+ (if (let ((switch-to-prev-buffer-wrap nil))
+ (switch-to-prev-buffer window 'kill))
(and dedicated-side (set-window-dedicated-p window 'side))
(window--delete window nil 'kill))))
;; Unrecord BUFFER in WINDOW.
And for:
-- Function: quit-restore-window &optional window bury-or-kill
...
As a consequence, if WINDOW is not deleted, invoking
‘switch-to-prev-buffer’ will usually show the buffer again.
need the same:
@@ -5292,7 +5340,8 @@ quit-restore-window
(set-window-dedicated-p window nil)
;; Try to switch to a previous buffer. Delete the window only if
;; that is not possible (Bug#48367).
- (if (switch-to-prev-buffer window bury-or-kill)
+ (if (let ((switch-to-prev-buffer-wrap nil))
+ (switch-to-prev-buffer window bury-or-kill))
(when (eq dedicated 'side)
(set-window-dedicated-p window 'side))
(window--delete window nil (eq bury-or-kill 'kill))
The Elisp manual doesn't mention that delete-windows-on
uses switch-to-prev-buffer, unlike it mentions other functions:
The ‘switch-to-prev-buffer’ command, in particular, is
used by ‘replace-buffer-in-windows’, ‘bury-buffer’ and ‘quit-window’ to
find a replacement buffer for a window.
but delete-windows-on still needs the same:
@@ -5116,7 +5164,8 @@ delete-windows-on
(t
;; In window switch to previous buffer.
(set-window-dedicated-p window nil)
- (switch-to-prev-buffer window 'bury)
+ (let ((switch-to-prev-buffer-wrap nil))
+ (switch-to-prev-buffer window 'bury))
;; Restore the dedicated 'side' flag.
(when (eq dedicated 'side)
(set-window-dedicated-p window 'side)))))
> Admittedly, "recent" is not very precise. The idea is, among others,
> that an intervening C-x b will make "recent invocations" appear as if
> they never happened.
'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.
> 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.
bug-gnu-emacs@HIDDEN:bug#69993; Package emacs.
Full text available.
Received: (at 69993) by debbugs.gnu.org; 31 Mar 2024 08:32:45 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Mar 31 04:32:45 2024
Received: from localhost ([127.0.0.1]:46549 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1rqqcO-0004ht-Hr
for submit <at> debbugs.gnu.org; Sun, 31 Mar 2024 04:32:44 -0400
Received: from mout.gmx.net ([212.227.15.19]:56627)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <rudalics@HIDDEN>) id 1rqqcK-0004hW-Hh
for 69993 <at> debbugs.gnu.org; Sun, 31 Mar 2024 04:32:43 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.at;
s=s31663417; t=1711873951; x=1712478751; i=rudalics@HIDDEN;
bh=Xf76vmeto8gTUm2iLQt3VQGQCltY8Q7FCusg0FvDoks=;
h=X-UI-Sender-Class:Date:Subject:To:Cc:References:From:
In-Reply-To;
b=Jbgy/inyFWMx/1Dz2Jtk9dx+6A7w9riWTPaR1y0uTnJLhYVy7w3bYhauA7eE+kYJ
2n4YWOOePtsXuup9YpI0vKYmUUAS8uT3ywtaPzjX78lHBtIdggqhaWBNxFcVDqzP3
VyjALiqvv41zmnFFskcrK103zBGBHyyWDTyfUazPR6GxR4A33IYEjpxYz94QSg8s+
IbHiN/IhqVtAZUgctmBu8sBwfhy0bDjAl9o48GpRU4Xbu1obrvKMqW7h6NC7RqJhR
311AK3H5gexulhmkmZpStX02lKixeCE6bMK+qgOQkjbwWGw6AX+jBLPoV3Yz/ytwr
V8VXVRPWLnSd+xzgsQ==
X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a
Received: from [192.168.31.113] ([212.95.5.108]) by mail.gmx.net (mrgmx005
[212.227.17.190]) with ESMTPSA (Nemesis) id 1N6siz-1suE2i2yo3-018MhR; Sun, 31
Mar 2024 10:32:31 +0200
Message-ID: <efd1b8d1-cec3-4e18-8aba-7fc2db9edaba@HIDDEN>
Date: Sun, 31 Mar 2024 10:32:30 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: bug#69993: Wrap window buffers while cycling
To: Juri Linkov <juri@HIDDEN>
References: <86h6gug41x.fsf@HIDDEN>
<3419df35-1b96-4a64-8ed7-722a05c58742@HIDDEN>
<86le66ckhj.fsf@HIDDEN>
<c2258795-4352-46af-85d3-0a4f1ba3d261@HIDDEN>
<86h6gs2lk7.fsf@HIDDEN>
<5c71ea64-0f97-4b90-af61-1156fe33f1ea@HIDDEN>
<86cyreu78w.fsf@HIDDEN>
<463c9242-56ef-4c99-9fe6-4b70be2071b2@HIDDEN>
<86sf0abeg3.fsf@HIDDEN>
<f3c9969f-64a0-491b-a5a8-7417a2cb9d45@HIDDEN>
<86v855ggkv.fsf@HIDDEN>
<91327e7b-d0a5-4f3a-a1f8-218d118608d6@HIDDEN>
<86sf07bnl4.fsf@HIDDEN>
Content-Language: en-US
From: martin rudalics <rudalics@HIDDEN>
In-Reply-To: <86sf07bnl4.fsf@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: base64
X-Provags-ID: V03:K1:UNzX+dNPpyj9CYOksz1qbM1oLGRMZxKM9Sgv+Q0dIV95j545t1P
DocO379Q8a0vw3ys9gJKL3esEoyOyq34LkBfheHar67aPqjezMeC8tEleRvYzYtNef9JNZW
SkeyeeA2RrrO8P1IYCNF7BC82+MUQVRx6pV188CCbbwSKxqaEbYq0oVLeAbZVXRS/9sKHAI
mBWLaAe90JopfJXTadfCw==
X-Spam-Flag: NO
UI-OutboundReport: notjunk:1;M01:P0:Q0ajuizSM/I=;F5WRqA28wa2PcPxbyVJRVZd1vkg
2FEg8L1ftAwMtUHL/rEtOHxrAe0RgadK17UoMGGnQ0cFx2kUNI0Q+10DGgzmQFKk7jaMyHZGU
LUf7UIkzLjoeNLNOsi/jitjPDzgRugbyqSzTsHiRl6ibur3YaG3dmjxwY6NLviDLIL9zFT2kY
j3MUPGHNb3DFT5Olce9R1gQxMPDU6drBP/u6UvW/4ABMxLxCDkKpqng2cMtIE7Va7K94eUI9t
IsS4hoGbcOv1bZwn0NJ3npV+4SBG7MHktylwTq05iWTDKWQDBodCN0fiIjFOo1ur6TnzolYCi
FUgNaBeyD3ji1aP75ONpy+I0bQdh+qQ2QQFtninIOPJj/ON9oujiWHhCvCRseU1rCHPoIeHDb
N5DE2gQw1MxsWUhCPG60mfttN7WQJ6XRlS8gNQlvqbjmH9iMoCJV4c8DvjzY4w4n+BPiZz5Da
xdIuncdgsONsYhbilguWQdVYQN1ZLWTjViu0s10heLyjLhMWwgxuY3+MBEE9rBzDXw2XdIpBx
MA7FYdALGtlIMa73tDHwi2Mrn730eauE0XWfFNazeuHhVfvFL8Tn+OcEFetvmkPPOGEXzdzOH
zSs3p7YZbfx/zKrxivI/nfEwokX+eu0+CJv5U03XAHFyhptJlzC2eQy48WFE5XShk3mih/nk2
w6LhTObKtlVURRJJqX17Ymk2esEjn3jQW/GXMW4cINNk6A3BcuWmCBHn38Mmi8Ub2bsX0glCV
LXIl4zsOtFOQNuvtX0qI0m1beincI8H4xOAp0xw7aRi8ndfI3Jd6uVs5uyKZ/7YzPFqPHmRoG
mOApvubI3QXiL1ws6APOrCQi6k3xvLYpUSgX3hUxyXx/93GlFZDWyX8ZKAbVpU+SsJ
X-Spam-Score: 2.8 (++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
has NOT identified this incoming email as spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
the administrator of that system for details.
Content preview: >> - I do like the idea of having an option to constrain
buffers switched >> to via C-x <left> and C-x <right> to those shown in that
window >> before. >> >> - I do like the idea of having an option [...]
Content analysis details: (2.8 points, 10.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
-0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at https://www.dnswl.org/,
low trust [212.227.15.19 listed in list.dnswl.org]
-0.0 SPF_PASS SPF: sender matches SPF record
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail
provider (rudalics[at]gmx.at)
-0.0 RCVD_IN_MSPIKE_H3 RBL: Good reputation (+3)
[212.227.15.19 listed in wl.mailspike.net]
0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record
3.6 RCVD_IN_SBL_CSS RBL: Received via a relay in Spamhaus SBL-CSS
[212.95.5.108 listed in zen.spamhaus.org]
-0.0 RCVD_IN_MSPIKE_WL Mailspike good senders
X-Debbugs-Envelope-To: 69993
Cc: 69993 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 1.8 (+)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
has NOT identified this incoming email as spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
the administrator of that system for details.
Content preview: >> - I do like the idea of having an option to constrain
buffers switched >> to via C-x <left> and C-x <right> to those shown in that
window >> before. >> >> - I do like the idea of having an option [...]
Content analysis details: (1.8 points, 10.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
-0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at https://www.dnswl.org/,
low trust
[212.227.15.19 listed in list.dnswl.org]
3.6 RCVD_IN_SBL_CSS RBL: Received via a relay in Spamhaus SBL-CSS
[212.95.5.108 listed in zen.spamhaus.org]
-0.0 RCVD_IN_MSPIKE_H3 RBL: Good reputation (+3)
[212.227.15.19 listed in wl.mailspike.net]
-0.0 SPF_PASS SPF: sender matches SPF record
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail
provider (rudalics[at]gmx.at)
0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record
-0.0 RCVD_IN_MSPIKE_WL Mailspike good senders
-1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list
manager
ID4+IC0gSSBkbyBsaWtlIHRoZSBpZGVhIG9mIGhhdmluZyBhbiBvcHRpb24gdG8gY29uc3Ry
YWluIGJ1ZmZlcnMgc3dpdGNoZWQNCiA+PiAgICB0byB2aWEgQy14IDxsZWZ0PiBhbmQgQy14
IDxyaWdodD4gdG8gdGhvc2Ugc2hvd24gaW4gdGhhdCB3aW5kb3cNCiA+PiAgICBiZWZvcmUu
DQogPj4NCiA+PiAtIEkgZG8gbGlrZSB0aGUgaWRlYSBvZiBoYXZpbmcgYW4gb3B0aW9uIGNv
bnRyb2xsaW5nIHdoZXRoZXIgQy14IDxsZWZ0Pg0KID4+ICAgIGFuZCBDLXggPHJpZ2h0PiBz
aG91bGQgd3JhcCB0byB0aGUgbGFzdC9maXJzdCBidWZmZXIgKHJlZ2FyZGxlc3Mgb2YNCiA+
PiAgICB3aGV0aGVyIGJ1ZmZlcnMgc3dpdGNoZWQgdG8gYXBwZWFyZWQgaW4gdGhlIHdpbmRv
dyBiZWZvcmUgb3Igbm90KS4NCiA+Pg0KID4+IC0gSSBhZ3JlZSB0aGF0IHRoZSBvcmRlcnMg
b2YgdGFicyBzaG93biBieSAndGFiLWxpbmUtbW9kZScgc2hvdWxkIG5vdA0KID4+ICAgIGNo
YW5nZSB3aGVuIGEgYnVmZmVyIHRoYXQgYWxyZWFkeSBhcHBlYXJlZCBpbiBhIHdpbmRvdyBp
cyBzaG93biBhZ2Fpbg0KID4+ICAgIGluIHRoYXQgd2luZG93IC0gdGhlIHdpbmRvdydzIGJ1
ZmZlciBpcyBhbHJlYWR5IGhpZ2hsaWdodGVkDQogPj4gICAgYXBwcm9wcmlhdGVseSBpbiB0
aGUgdGFiIGxpbmUgaW4gdGhhdCBjYXNlLg0KID4NCiA+IFdoZW4geW91IHNheSB0aGF0IGEg
YnVmZmVyIGlzIHNob3duIGFnYWluIGluIHRoYXQgd2luZG93LA0KID4gZG8geW91IG1lYW4g
c2hvd2luZyB0aGUgYnVmZmVyIHdpdGggQy14IDxsZWZ0PiBhbmQgQy14IDxyaWdodD4NCiA+
IG9yIHdpdGggQy14IGI/DQoNClRoZSBFbGlzcCBtYW51YWwgc2F5cyBhYm91dCAnc3dpdGNo
LXRvLXByZXYtYnVmZmVyJw0KDQogICAgICBUaGUgcHJldmlvdXMgYnVmZmVyIGlzIHVzdWFs
bHkgdGhlIGJ1ZmZlciBzaG93biBiZWZvcmUgdGhlIGJ1ZmZlcg0KICAgICAgY3VycmVudGx5
IHNob3duIGluIFdJTkRPVy4gIEhvd2V2ZXIsIGEgYnVmZmVyIHRoYXQgaGFzIGJlZW4gYnVy
aWVkDQogICAgICBvciBraWxsZWQsIG9yIGhhcyBiZWVuIGFscmVhZHkgc2hvd24gYnkgYSBy
ZWNlbnQgaW52b2NhdGlvbiBvZg0KICAgICAg4oCYc3dpdGNoLXRvLXByZXYtYnVmZmVy4oCZ
LCBkb2VzIG5vdCBxdWFsaWZ5IGFzIHByZXZpb3VzIGJ1ZmZlci4NCg0KYW5kIGFib3V0ICdz
d2l0Y2gtdG8tbmV4dC1idWZmZXInDQoNCiAgICAgIFRoaXMgY29tbWFuZCBzd2l0Y2hlcyB0
byB0aGUgbmV4dCBidWZmZXIgaW4gV0lORE9XLCB0aHVzIHVuZG9pbmcNCiAgICAgIHRoZSBl
ZmZlY3Qgb2YgdGhlIGxhc3Qg4oCYc3dpdGNoLXRvLXByZXYtYnVmZmVy4oCZIGNvbW1hbmQg
aW4gV0lORE9XLg0KICAgICAgVGhlIGFyZ3VtZW50IFdJTkRPVyBtdXN0IGJlIGEgbGl2ZSB3
aW5kb3cgYW5kIGRlZmF1bHRzIHRvIHRoZQ0KICAgICAgc2VsZWN0ZWQgb25lLg0KDQpBZG1p
dHRlZGx5LCAicmVjZW50IiBpcyBub3QgdmVyeSBwcmVjaXNlLiAgVGhlIGlkZWEgaXMsIGFt
b25nIG90aGVycywNCnRoYXQgYW4gaW50ZXJ2ZW5pbmcgQy14IGIgd2lsbCBtYWtlICJyZWNl
bnQgaW52b2NhdGlvbnMiIGFwcGVhciBhcyBpZg0KdGhleSBuZXZlciBoYXBwZW5lZC4NCg0K
ID4+IEJ1dCB0aGlzIGxhc3QgcmVxdWlyZW1lbnQgb2YgJ3RhYi1saW5lLW1vZGUnIHNob3Vs
ZCBub3QgYWZmZWN0IHRoZSBvcmRlcg0KID4+IG9mIGJ1ZmZlcnMgaW4gYSB3aW5kb3cncyBs
aXN0IG9mIHByZXZpb3VzIGFuZCBuZXh0IGJ1ZmZlcnMuDQogPg0KID4gV2hlbiB0aGUgdGFi
LWxpbmUgd2lsbCBzaG93IHRoZSBzYW1lIG9yZGVyIG9mIHByZXYvbmV4dCBidWZmZXJzDQog
PiBhZnRlciBDLXggPGxlZnQ+IGFuZCBDLXggPHJpZ2h0PiBvciBldmVuIGFmdGVyIEMteCBi
LCBkb2VzIHRoaXMNCiA+IG1lYW4gdGhlIG9yZGVyIG9mIHByZXYvbmV4dCBidWZmZXJzIGlz
IG5vdCBhZmZlY3RlZD8NCg0KTm8uICBBbGwgb2YgdGhlc2UgYWZmZWN0IHRoZSBvcmRlciwg
YWxiZWl0IGluIGRpc3RpbmN0IHdheXMuICBJIHRoaW5rDQp0aGUgZm9sbG93aW5nIGlzIHBy
b2JsZW1hdGljOg0KDQogICAoZGVmdW4gdGFiLWxpbmUtc3dpdGNoLXRvLXByZXYtdGFiICgm
b3B0aW9uYWwgZXZlbnQpDQogICAgICJTd2l0Y2ggdG8gdGhlIHByZXZpb3VzIHRhYidzIGJ1
ZmZlci4NCiAgIEl0cyBlZmZlY3QgaXMgdGhlIHNhbWUgYXMgdXNpbmcgdGhlIGBwcmV2aW91
cy1idWZmZXInIGNvbW1hbmQNCiAgIChcXFtwcmV2aW91cy1idWZmZXJdKS4iDQoNCklmIHRo
ZSAicHJldmlvdXMgdGFiIiBkb2VzIG5vdCBzaG93IHRoZSBidWZmZXIgJ3N3aXRjaC10by1w
cmV2LWJ1ZmZlcicNCndvdWxkIHN3aXRjaCB0bywgdGhlbiB0aGUgZG9jIGlzIHdyb25nLiAg
SSdtIG5vdCBzdXJlIHdoZXRoZXINCid0YWItbGluZS10YWJzLXdpbmRvdy1idWZmZXJzJyBj
YW4gZ3VhcmFudGVlIHRoYXQgdGhpcyBjaG9vc2VzIHRoZSBzYW1lDQpidWZmZXIgJ3N3aXRj
aC10by1wcmV2LWJ1ZmZlcicgd291bGQgc3dpdGNoIHRvLCB0aG91Z2guICBJZiBpdCBkb2Vz
bid0LA0KdGhlbiB0aGUgZWZmZWN0IHNob3VsZCBiZSB0aGF0IG9mIEMteCBiIHN3aXRjaGlu
ZyB0byBhIGJ1ZmZlciBlYXJsaWVyDQpzaG93biBpbiB0aGF0IHdpbmRvdy4gIEJUVywgYnVy
eWluZyBhIGJ1ZmZlciByZW1vdmVzIGl0IGZyb20gdGhlIHRhYg0KbGluZSBidXQgZG9lcyBu
b3QgcHJldmVudCAnc3dpdGNoLXRvLXByZXYtYnVmZmVyJyBmcm9tIHN3aXRjaGluZyB0byBp
dCAtDQppdCBqdXN0IG1ha2VzIGl0IHZlcnkgdW5saWtlbHkgSUlSQy4NCg0KbWFydGluDQo=
bug-gnu-emacs@HIDDEN:bug#69993; Package emacs.
Full text available.Received: (at 69993) by debbugs.gnu.org; 30 Mar 2024 18:24:57 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Mar 30 14:24:57 2024 Received: from localhost ([127.0.0.1]:46150 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1rqdNx-0006TL-0R for submit <at> debbugs.gnu.org; Sat, 30 Mar 2024 14:24:57 -0400 Received: from relay6-d.mail.gandi.net ([217.70.183.198]:51945) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <juri@HIDDEN>) id 1rqdNn-0006Rt-Ka for 69993 <at> debbugs.gnu.org; Sat, 30 Mar 2024 14:24:48 -0400 Received: by mail.gandi.net (Postfix) with ESMTPSA id 29D5CC0002; Sat, 30 Mar 2024 18:24:37 +0000 (UTC) From: Juri Linkov <juri@HIDDEN> To: martin rudalics <rudalics@HIDDEN> Subject: Re: bug#69993: Wrap window buffers while cycling In-Reply-To: <91327e7b-d0a5-4f3a-a1f8-218d118608d6@HIDDEN> (martin rudalics's message of "Sat, 30 Mar 2024 10:37:27 +0100") Organization: LINKOV.NET References: <86h6gug41x.fsf@HIDDEN> <3419df35-1b96-4a64-8ed7-722a05c58742@HIDDEN> <86le66ckhj.fsf@HIDDEN> <c2258795-4352-46af-85d3-0a4f1ba3d261@HIDDEN> <86h6gs2lk7.fsf@HIDDEN> <5c71ea64-0f97-4b90-af61-1156fe33f1ea@HIDDEN> <86cyreu78w.fsf@HIDDEN> <463c9242-56ef-4c99-9fe6-4b70be2071b2@HIDDEN> <86sf0abeg3.fsf@HIDDEN> <f3c9969f-64a0-491b-a5a8-7417a2cb9d45@HIDDEN> <86v855ggkv.fsf@HIDDEN> <91327e7b-d0a5-4f3a-a1f8-218d118608d6@HIDDEN> Date: Sat, 30 Mar 2024 20:24:19 +0200 Message-ID: <86sf07bnl4.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/30.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-GND-Sasl: juri@HIDDEN X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 69993 Cc: 69993 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.7 (-) > - I do like the idea of having an option to constrain buffers switched > to via C-x <left> and C-x <right> to those shown in that window > before. > > - I do like the idea of having an option controlling whether C-x <left> > and C-x <right> should wrap to the last/first buffer (regardless of > whether buffers switched to appeared in the window before or not). > > - I agree that the orders of tabs shown by 'tab-line-mode' should not > change when a buffer that already appeared in a window is shown again > in that window - the window's buffer is already highlighted > appropriately in the tab line in that case. When you say that a buffer is shown again in that window, do you mean showing the buffer with C-x <left> and C-x <right> or with C-x b? > But this last requirement of 'tab-line-mode' should not affect the order > of buffers in a window's list of previous and next buffers. When the tab-line will show the same order of prev/next buffers after C-x <left> and C-x <right> or even after C-x b, does this mean the order of prev/next buffers is not affected?
bug-gnu-emacs@HIDDEN:bug#69993; Package emacs.
Full text available.
Received: (at 69993) by debbugs.gnu.org; 30 Mar 2024 09:37:38 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Mar 30 05:37:38 2024
Received: from localhost ([127.0.0.1]:43985 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1rqV9e-0001wy-86
for submit <at> debbugs.gnu.org; Sat, 30 Mar 2024 05:37:38 -0400
Received: from mout.gmx.net ([212.227.15.18]:54543)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <rudalics@HIDDEN>) id 1rqV9c-0001wm-C7
for 69993 <at> debbugs.gnu.org; Sat, 30 Mar 2024 05:37:36 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.at;
s=s31663417; t=1711791448; x=1712396248; i=rudalics@HIDDEN;
bh=YvHmON1Q61J+LtsvRGR1Q3odTcAQTXBrLLk9VOrAXYQ=;
h=X-UI-Sender-Class:Date:Subject:To:Cc:References:From:
In-Reply-To;
b=PhNHyY6c4GSItLJKaic7zGpbf9O8PC1oJS0BDQc3OpK14tR+Tot8JogWxxUjb37a
VDAI9LHYOMoPchAB+engI6Q6wyI66dVo2vSE0HTGmJM4L/xjYoflZ1EzHDVMYR+6z
RYkXA3mbfQ4WavdSdXTQSXW19hxBYFtwlHHo2EWQSOqCthbwUkrLyc34SlWRZS5nM
Ru/gqxb7wIzc8jc07DabM73xvvJ90LF1bIqFHpXNPVM7dvmUe1OkTI/WOdN9JGsAl
8drlPUcgciQUu7WNW4Rc6tjvDh/c4yoL4QHict2Lgleng3QrHVDicHxEHiy+xDG4+
X2r2JIyVqUnYviBm4w==
X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a
Received: from [192.168.31.113] ([46.125.249.110]) by mail.gmx.net (mrgmx004
[212.227.17.190]) with ESMTPSA (Nemesis) id 1MI5UD-1s1n1r0yoh-00FFOc; Sat, 30
Mar 2024 10:37:28 +0100
Message-ID: <91327e7b-d0a5-4f3a-a1f8-218d118608d6@HIDDEN>
Date: Sat, 30 Mar 2024 10:37:27 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: bug#69993: Wrap window buffers while cycling
To: Juri Linkov <juri@HIDDEN>
References: <86h6gug41x.fsf@HIDDEN>
<3419df35-1b96-4a64-8ed7-722a05c58742@HIDDEN>
<86le66ckhj.fsf@HIDDEN>
<c2258795-4352-46af-85d3-0a4f1ba3d261@HIDDEN>
<86h6gs2lk7.fsf@HIDDEN>
<5c71ea64-0f97-4b90-af61-1156fe33f1ea@HIDDEN>
<86cyreu78w.fsf@HIDDEN>
<463c9242-56ef-4c99-9fe6-4b70be2071b2@HIDDEN>
<86sf0abeg3.fsf@HIDDEN>
<f3c9969f-64a0-491b-a5a8-7417a2cb9d45@HIDDEN>
<86v855ggkv.fsf@HIDDEN>
Content-Language: en-US
From: martin rudalics <rudalics@HIDDEN>
In-Reply-To: <86v855ggkv.fsf@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K1:Pystew+nsSlvTXZJH54gnJhX3oFfaKYHB1NXmz4M6Rbm07pBvuq
4SMlegidlzBihqFuvHvYLfq8WQ6rPCPUeW9sYqYX+DD4GddSgTK7gpQm1+poeEWv+nbze5k
ZKBZzR5TNB3UnyyVF722txiGzE6dVnFnPs/7E9QHop53fYSEqt6Ny43pI61wh/9lWnhtlJC
4tXvqiDQVhJ97efgDagfg==
X-Spam-Flag: NO
UI-OutboundReport: notjunk:1;M01:P0:rc4Z43aEq0M=;/Bof01i2gv8PqHe5+4MGok2D7bm
tNAMvEYwkseHqKfA9hqJjP6GRxol+ufuqks2B9ER+zOIwqxfBoyMp0nWaqZuJtSCwOztC/95O
o6Nf1h32if9XWmXSaE1EJl6BJU+ZzxpwzE8d0znDxb3wvzfbS+6idez5GjJdMYSUEl0uGBNeN
xBDIXKvXLPQT9SudVALosS5mcaPIbxU0/x7bQLxrFxrOILOtIKbsmpcd0Z2RC3Rdu4xB+4Sgv
5kIwNR5OP687mOC4C8RZRTRglCRhM9u+G04+vyt4tdx8x0gU1Y+njrDgSyHAWHS6SfEEvjpBm
tR4mP1sSvVfTQUxPJnbJwVKd1fOfz1eL9iv1Bw9JGmcMxw9+8XdTqFZdiY5XdSRDjBhgzbIcy
MlkahDzYWRsfr489DvfcliIoeOJ4nriYLgxvEHo6sVayMHfRW/bt3J6jhdyxfQuzu7v86SBbx
s4czpRDa5WPCq7pohMQhC5SKemIMjsl7zsTrlEZetEOm/CP3vnfMPBsndwBUtGIdR8LLyNmzP
HMHUopExIjrXbKP1IWiFyKzwjKNPO3174t4Mh9aCnhyxFEIAi2fZdyj+jnIQAZyC1nt/UQX1s
E5d1Z6ch2hXJnymDxXjM72wNY/mKyjxzLE3TZpHc3oIMhE95bT7dA2VXAxoHORzahfJ9dSs7i
7q8xXfnSE/dgFIfBzsWbVc+1YwmhdQHsLCse0oNnlxdbpPMae0nPlmdjyxjqvGW3xCmdHCJxl
Mp8tix0eUAkto94vJ/HKI+/0XQlsDdRQF7xc2pb3M24yUHlQL5FefXaLOkTZAi5692L7VJvNX
JAUI3kOjRb/ah+f+ItbzEansH9DXXgOyvzn4Vmjl2ksKo=
X-Spam-Score: 4.4 (++++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
has NOT identified this incoming email as spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
the administrator of that system for details.
Content preview: > Sorry for the confusion. This feature request was only
about C-x C-left. ... and about C-x C-right presumably. > C-x b was just
speculation about a possible separate option.
Content analysis details: (4.4 points, 10.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
-0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at https://www.dnswl.org/,
low trust [212.227.15.18 listed in list.dnswl.org]
3.6 RCVD_IN_SBL_CSS RBL: Received via a relay in Spamhaus SBL-CSS
[46.125.249.110 listed in zen.spamhaus.org]
1.5 RCVD_IN_SORBS_WEB RBL: SORBS: sender is an abusable web server
[46.125.249.110 listed in dnsbl.sorbs.net]
-0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2)
[212.227.15.18 listed in wl.mailspike.net]
-0.0 SPF_PASS SPF: sender matches SPF record
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail
provider (rudalics[at]gmx.at)
0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record
X-Debbugs-Envelope-To: 69993
Cc: 69993 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 3.4 (+++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
has NOT identified this incoming email as spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
the administrator of that system for details.
Content preview: > Sorry for the confusion. This feature request was only
about C-x C-left. ... and about C-x C-right presumably. > C-x b was just speculation
about a possible separate option.
Content analysis details: (3.4 points, 10.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
-0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at https://www.dnswl.org/,
low trust
[212.227.15.18 listed in list.dnswl.org]
1.5 RCVD_IN_SORBS_WEB RBL: SORBS: sender is an abusable web server
[46.125.249.110 listed in dnsbl.sorbs.net]
-0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2)
[212.227.15.18 listed in wl.mailspike.net]
3.6 RCVD_IN_SBL_CSS RBL: Received via a relay in Spamhaus SBL-CSS
[46.125.249.110 listed in zen.spamhaus.org]
-0.0 SPF_PASS SPF: sender matches SPF record
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail
provider (rudalics[at]gmx.at)
0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record
-1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list
manager
> Sorry for the confusion. This feature request was only about C-x C-left.
... and about C-x C-right presumably.
> C-x b was just speculation about a possible separate option.
Please can we start again from scratch please:
- I do like the idea of having an option to constrain buffers switched
to via C-x <left> and C-x <right> to those shown in that window
before.
- I do like the idea of having an option controlling whether C-x <left>
and C-x <right> should wrap to the last/first buffer (regardless of
whether buffers switched to appeared in the window before or not).
- I agree that the orders of tabs shown by 'tab-line-mode' should not
change when a buffer that already appeared in a window is shown again
in that window - the window's buffer is already highlighted
appropriately in the tab line in that case.
But this last requirement of 'tab-line-mode' should not affect the order
of buffers in a window's list of previous and next buffers.
martin
bug-gnu-emacs@HIDDEN:bug#69993; Package emacs.
Full text available.Received: (at 69993) by debbugs.gnu.org; 29 Mar 2024 16:35:59 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Mar 29 12:35:59 2024 Received: from localhost ([127.0.0.1]:43286 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1rqFCw-0002ce-Pl for submit <at> debbugs.gnu.org; Fri, 29 Mar 2024 12:35:59 -0400 Received: from relay7-d.mail.gandi.net ([217.70.183.200]:44387) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <juri@HIDDEN>) id 1rqFCs-0002bh-EP for 69993 <at> debbugs.gnu.org; Fri, 29 Mar 2024 12:35:54 -0400 Received: by mail.gandi.net (Postfix) with ESMTPSA id 3919420002; Fri, 29 Mar 2024 16:35:46 +0000 (UTC) From: Juri Linkov <juri@HIDDEN> To: martin rudalics <rudalics@HIDDEN> Subject: Re: bug#69993: Wrap window buffers while cycling In-Reply-To: <f3c9969f-64a0-491b-a5a8-7417a2cb9d45@HIDDEN> (martin rudalics's message of "Fri, 29 Mar 2024 09:45:24 +0100") Organization: LINKOV.NET References: <86h6gug41x.fsf@HIDDEN> <3419df35-1b96-4a64-8ed7-722a05c58742@HIDDEN> <86le66ckhj.fsf@HIDDEN> <c2258795-4352-46af-85d3-0a4f1ba3d261@HIDDEN> <86h6gs2lk7.fsf@HIDDEN> <5c71ea64-0f97-4b90-af61-1156fe33f1ea@HIDDEN> <86cyreu78w.fsf@HIDDEN> <463c9242-56ef-4c99-9fe6-4b70be2071b2@HIDDEN> <86sf0abeg3.fsf@HIDDEN> <f3c9969f-64a0-491b-a5a8-7417a2cb9d45@HIDDEN> Date: Fri, 29 Mar 2024 18:35:12 +0200 Message-ID: <86v855ggkv.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/30.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-GND-Sasl: juri@HIDDEN X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 69993 Cc: 69993 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.7 (-) >>> (1) The classic behavior where switching may show a buffer never shown >>> in the window before. I suppose you mean that >>> 'switch-to-prev-buffer-wrap' does not affect it. If that's the >>> case, please say so. >> >> Indeed, 'switch-to-prev-buffer-wrap' does not affect it. >> Switching to a buffer that was never shown in the window >> should still reset the list of next-buffers to nil. >> >>> (2) The new behavior where switching may only show buffers shown in that >>> window before. For this you want to either wrap or not. So the >>> option 'switch-to-prev-buffer-wrap' will affect (2) only. Right? >> >> 'switch-to-prev-buffer-wrap' will affect only 'C-x C-left' and 'C-x C-right' >> cycling buffers shown in that window before. > > I'm still confused. Do you mean that C-x b, when it switches to a > buffer previously shown in that window, should not change the ordering > of buffers previously shown in that window? And behave so if and only > if 'switch-to-prev-buffer-wrap' is non-nil? Then what would users do if > they (1) want to use your new option but (2) still want C-x b or C-x > C-left make that buffer the most previously used one in that window? Sorry for the confusion. This feature request was only about C-x C-left. C-x b was just speculation about a possible separate option.
bug-gnu-emacs@HIDDEN:bug#69993; Package emacs.
Full text available.Received: (at 69993) by debbugs.gnu.org; 29 Mar 2024 08:45:36 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Mar 29 04:45:36 2024 Received: from localhost ([127.0.0.1]:41678 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1rq7rk-0005U7-0G for submit <at> debbugs.gnu.org; Fri, 29 Mar 2024 04:45:36 -0400 Received: from mout.gmx.net ([212.227.15.19]:50391) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <rudalics@HIDDEN>) id 1rq7rg-0005TA-ND for 69993 <at> debbugs.gnu.org; Fri, 29 Mar 2024 04:45:33 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.at; s=s31663417; t=1711701925; x=1712306725; i=rudalics@HIDDEN; bh=dtecStb3F/mhO7e85VZLjEsEE1ThDNBcZfGJlau4noM=; h=X-UI-Sender-Class:Date:Subject:To:Cc:References:From: In-Reply-To; b=Tdvttyxdsn7sTy39Lpy0pRKUbo/BpahQCKXDS5lInkptR6TXWsblhdpYlpToMYlD 7IFhfdJlYCly7adkFTuLMpfzcQFYsUIIJ+IfN12lC3tXnR0G4r7fLD7e8ojfAxMRX aSy/YchEFNsJroJWpu8zNwVEB6q5YTzmkE9hz0rZ3NYBsgDRsruKBVFjRaA1AA8lD Y3+PM9uVGLTx5GdtezEJHqknfgpABRi65C/EjSA+Us8WpPTFPrsXDJUlBKaCDNmTk /2dfsKlRrR7Z8vsFfCW2qoG5fj3zEdB5iffSl2Afg/qYiMt+J2DUa04t/5B/aaarB lyRK1FBC2YyHcO0Rvg== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from [192.168.31.113] ([46.125.249.18]) by mail.gmx.net (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MV67o-1sElTn07cM-00SB2q; Fri, 29 Mar 2024 09:45:25 +0100 Message-ID: <f3c9969f-64a0-491b-a5a8-7417a2cb9d45@HIDDEN> Date: Fri, 29 Mar 2024 09:45:24 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#69993: Wrap window buffers while cycling To: Juri Linkov <juri@HIDDEN> References: <86h6gug41x.fsf@HIDDEN> <3419df35-1b96-4a64-8ed7-722a05c58742@HIDDEN> <86le66ckhj.fsf@HIDDEN> <c2258795-4352-46af-85d3-0a4f1ba3d261@HIDDEN> <86h6gs2lk7.fsf@HIDDEN> <5c71ea64-0f97-4b90-af61-1156fe33f1ea@HIDDEN> <86cyreu78w.fsf@HIDDEN> <463c9242-56ef-4c99-9fe6-4b70be2071b2@HIDDEN> <86sf0abeg3.fsf@HIDDEN> Content-Language: en-US From: martin rudalics <rudalics@HIDDEN> In-Reply-To: <86sf0abeg3.fsf@HIDDEN> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:smI0BphHrDLF06vOm5+zKlx/8ax9lMcsST6wzMvzMujUNTpWWCa /y1aCR1DkLclVjSDLEqlsoWZ7tS//u4m3w/T02mSkUbEfZTdc0gsW0UPUdqYk47HWL7Zkjj iaay4RCNc3sp+EL5NLeee/vAvtUW4XwtP4CBiQR+4bSQoCZ6hdrJd8HlZD50+pt6nlN3Yfo JaUiWWKeD88iaDjUWNLbQ== X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:8Wu9XaUraUk=;XJUwIZs50EEMKRmx/kyz1ZSINMB nKOpuVExkM2HyIpkgO3UgVyKzg52Qc5w+HmhWMnV80DwJEGKVDfnzsEdBf31ny2vC1GUnj6my DrsLK6ywCK2PCBO8nODJgjmBXmlFA9ALVzGJlnDGv/+Ei91grdqK8LD0Ln6kE1KU1IkECcj+V 0+ER2n0fFYevZjWDpi2SkVkDSlUfboVByHMrW6JtloieFYD/kX2cLNmyzVzZIYlq+X5C8hVqG sRVaIzxn4tcsldL7S25dyv2pHB5nPZK6rIZxAZtzD6+QLHSG1tDiqaDxZaDOJtmybTLPWx6LR hF2LNJmJWuURyBLU+lhe2LKwdYzfjMBzYD5/nkbuDJVFIePb01x230FgLJyqOhsvzHLuu0hl7 jrt779zSimlOQQjqjrA9Rj9mrUbEtdD2Ei/EKqq6fMwktuwgmtI3vK77Cf5sRDza4ErhlkY0t R5yECRGJjtYqBjBT+7hb+xytnznK+MlmWjt6MvcEx/iCZqCVTHEWJBbaZMTCldvAMNkSIRYwr cXMkWuiXnwJ4KzKzMDyvsQyhKpV/XaXGWyr7bBvUFc1k5SGI5jmUghKgJ0rNzANT1GYVH7EJ8 BtWhCGBB0IoPBkaNxzxkfvGuJSFZvN5p8eXeUnebQwmje8cv7u13iTSUjf+0eP28O41LEDCAk /E1B/CLfWYl++OIHxOb9s6aFhgJzBsXqsA5QK+aCl2nyQeIeo9nWt6q/NA242HvprD6y9hYlc uyTPX2wM5K/FURBTzTfZnDRtHy17NB9uSupNII9PwUsX26YIVzg94bl711BuMe42zBRqLxGCb scinDJokXYmaNMUSsEVvhUHm58l12OKT+UXnNg9t8sB/62u0D1cn6ZZDNQk/e+ELqz X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 69993 Cc: 69993 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.7 (-) >> (1) The classic behavior where switching may show a buffer never shown >> in the window before. I suppose you mean that >> 'switch-to-prev-buffer-wrap' does not affect it. If that's the >> case, please say so. > > Indeed, 'switch-to-prev-buffer-wrap' does not affect it. > Switching to a buffer that was never shown in the window > should still reset the list of next-buffers to nil. > >> (2) The new behavior where switching may only show buffers shown in that >> window before. For this you want to either wrap or not. So the >> option 'switch-to-prev-buffer-wrap' will affect (2) only. Right? > > 'switch-to-prev-buffer-wrap' will affect only 'C-x C-left' and 'C-x C-right' > cycling buffers shown in that window before. I'm still confused. Do you mean that C-x b, when it switches to a buffer previously shown in that window, should not change the ordering of buffers previously shown in that window? And behave so if and only if 'switch-to-prev-buffer-wrap' is non-nil? Then what would users do if they (1) want to use your new option but (2) still want C-x b or C-x C-left make that buffer the most previously used one in that window? martin
bug-gnu-emacs@HIDDEN:bug#69993; Package emacs.
Full text available.Received: (at 69993) by debbugs.gnu.org; 28 Mar 2024 18:05:19 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Mar 28 14:05:19 2024 Received: from localhost ([127.0.0.1]:41102 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1rpu7r-0001zm-El for submit <at> debbugs.gnu.org; Thu, 28 Mar 2024 14:05:19 -0400 Received: from relay6-d.mail.gandi.net ([2001:4b98:dc4:8::226]:45115) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <juri@HIDDEN>) id 1rpu7e-0001xj-Hw for 69993 <at> debbugs.gnu.org; Thu, 28 Mar 2024 14:05:07 -0400 Received: by mail.gandi.net (Postfix) with ESMTPSA id 491E9C0003; Thu, 28 Mar 2024 18:04:57 +0000 (UTC) From: Juri Linkov <juri@HIDDEN> To: martin rudalics <rudalics@HIDDEN> Subject: Re: bug#69993: Wrap window buffers while cycling In-Reply-To: <463c9242-56ef-4c99-9fe6-4b70be2071b2@HIDDEN> (martin rudalics's message of "Thu, 28 Mar 2024 10:19:23 +0100") Organization: LINKOV.NET References: <86h6gug41x.fsf@HIDDEN> <3419df35-1b96-4a64-8ed7-722a05c58742@HIDDEN> <86le66ckhj.fsf@HIDDEN> <c2258795-4352-46af-85d3-0a4f1ba3d261@HIDDEN> <86h6gs2lk7.fsf@HIDDEN> <5c71ea64-0f97-4b90-af61-1156fe33f1ea@HIDDEN> <86cyreu78w.fsf@HIDDEN> <463c9242-56ef-4c99-9fe6-4b70be2071b2@HIDDEN> Date: Thu, 28 Mar 2024 19:57:56 +0200 Message-ID: <86sf0abeg3.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/30.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-GND-Sasl: juri@HIDDEN X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 69993 Cc: 69993 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.7 (-) >>> What is the "fixed order"? When I use C-x b, that buffer becomes the >>> one most recently shown in that window. >> >> The fixed order is similar to how tabs work in web browsers. >> It would be unexpected when switching to a tab will always >> move it to the end of the tab line. This is why it's unexpected >> for C-x b to move tabs when tab-line-mode is used. > > But the lists of previous and next buffers have to reflect the order in > which these buffers were shown in a window. You probably can't map them > directly to tabs. They are already mapped to tabs, and users happily used them for 5 years. The only remaining problem the users complain about is that switching buffers messes up the order. There is no problem in using a fixed order because buffers will be still ordered by the order they were shown in a window. Only need a way to switch between buffers already shown in a window. For users of tab-line-mode there is no difference whether to use 'C-x C-left' or 'C-x b' to switch to the previous buffer. >>> I think 'switch-to-prev-buffer-wrap' already confuses things. Wrapping, >>> for me, means to wrap around like when navigating on a ring of buffers. >>> Whether this should include buffers never shown in the window before is >>> a different issue IMO. And whether C-x b should change the order is yet >>> another issue. So maybe we need three options instead of one... >> >> I can't imagine why anyone would need wrapping when C-x C-left >> will visit hundreds of buffers never shown in the window. > > Emacs "wrapped" in that case ever since (with at least two buffers). The case of 'emacs -Q' has no practical significance. >> So we need only two options: wrapping buffers shown in the window, >> and to keep the fixed order of C-x b. So I will create a new request >> for the fixed order of C-x b. And here is the final patch for wrapping: > > I still don't agree with it. IMHO we have to cater for two cases: > > (1) The classic behavior where switching may show a buffer never shown > in the window before. I suppose you mean that > 'switch-to-prev-buffer-wrap' does not affect it. If that's the > case, please say so. Indeed, 'switch-to-prev-buffer-wrap' does not affect it. Switching to a buffer that was never shown in the window should still reset the list of next-buffers to nil. > (2) The new behavior where switching may only show buffers shown in that > window before. For this you want to either wrap or not. So the > option 'switch-to-prev-buffer-wrap' will affect (2) only. Right? 'switch-to-prev-buffer-wrap' will affect only 'C-x C-left' and 'C-x C-right' cycling buffers shown in that window before.
bug-gnu-emacs@HIDDEN:bug#69993; Package emacs.
Full text available.
Received: (at 69993) by debbugs.gnu.org; 28 Mar 2024 09:19:34 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Mar 28 05:19:34 2024
Received: from localhost ([127.0.0.1]:39046 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1rplv4-0002YA-Ak
for submit <at> debbugs.gnu.org; Thu, 28 Mar 2024 05:19:34 -0400
Received: from mout.gmx.net ([212.227.17.22]:57629)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <rudalics@HIDDEN>) id 1rplv1-0002XH-N8
for 69993 <at> debbugs.gnu.org; Thu, 28 Mar 2024 05:19:32 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.at;
s=s31663417; t=1711617564; x=1712222364; i=rudalics@HIDDEN;
bh=D+hbPkj7eTBTM8z7J05NO8tMwCi8OXApd4BfO1q94EQ=;
h=X-UI-Sender-Class:Date:Subject:To:Cc:References:From:
In-Reply-To;
b=Jd/dG5ifMzAnt6S7GulC6VahtE5OvnJVzGKmes271vt/LBnxmuhyBqAJuuuJW//l
C6bCv3w4vwToKj5K4zSlnf1FSakYrL0Kj01M0timT0uOq/L4B5Ewn9vgcFoQk5w0p
pzmpsbZQWNPZAlJc2iI3O5PE5HWYciW5RzTg//IJUGcXTsG9ecAzcEQHxtnJAYA+n
1rxZVnJSbyCDCtEMEjnrNm5FPzkedRJgWBF4s0uwE54U0cfaAGhqL8H90JTKjKOSb
uBvcU+XbiP31ReT1zNz/WbekyqtkJvM67bTIrUIq2vC8DuFGC3KfBsO71u3hKy73q
oA+IUad9danVLcKFCg==
X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a
Received: from [192.168.31.113] ([213.142.97.35]) by mail.gmx.net (mrgmx105
[212.227.17.168]) with ESMTPSA (Nemesis) id 1MhlKy-1sTURo1afQ-00dmB6; Thu, 28
Mar 2024 10:19:24 +0100
Message-ID: <463c9242-56ef-4c99-9fe6-4b70be2071b2@HIDDEN>
Date: Thu, 28 Mar 2024 10:19:23 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: bug#69993: Wrap window buffers while cycling
To: Juri Linkov <juri@HIDDEN>
References: <86h6gug41x.fsf@HIDDEN>
<3419df35-1b96-4a64-8ed7-722a05c58742@HIDDEN>
<86le66ckhj.fsf@HIDDEN>
<c2258795-4352-46af-85d3-0a4f1ba3d261@HIDDEN>
<86h6gs2lk7.fsf@HIDDEN>
<5c71ea64-0f97-4b90-af61-1156fe33f1ea@HIDDEN>
<86cyreu78w.fsf@HIDDEN>
Content-Language: en-US
From: martin rudalics <rudalics@HIDDEN>
In-Reply-To: <86cyreu78w.fsf@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K1:t2iD7o5s4XVNqctU1qxLNnPK1bgg/KTlYHAHfOqbF0qxTkXPnAg
N4CPdWpeqNxxLlGlZS/auPM/usATxlIRmoi0dnIop+HncMm8VnVm0tVdTvA+eIeyGw7vPCU
9A7vyUaa+/ehXody8E2tHKGfHly5nMgPZxQndmiops+PdaUlpmqxXW+mikDIW1XWPYBLz28
ei2NHalRkaXY+HQ3crvXw==
X-Spam-Flag: NO
UI-OutboundReport: notjunk:1;M01:P0:kJtgHGf4QkE=;4ZhUAe6RqIv+qJdWMiY5Mg8MLmd
Kg00WmDfKCWIb83nKQiftVNVTKNQny9LIMBcRcpjvB/hlvF39dkT9LNdaDrzo91Vmme8Tfp/x
x+xTsLt1BoLVRm1JnpYiQtX2NUlTqTjEYCJza1MPx5fqUbfP9blwYriNgW7KO4F+NCo+dUhF2
SfGobThuWgEd/ZFn8n8hqGAkoiBaSxf2GXva7W9ORzyb2C53yK1rn4zU1OPDElLvTrx4NCdsI
sXbgUte03OUYRjtdOHEKr5VzKZbwXZg92UawKolwtdnszcI3mMvYgSVoJP2aRUGhf2r77YK4S
M1Pvrs1t64womaWbKImNQ1FHej0F3ZgWK434q1Cnhb4wlnUaDvhbxTO/82wVqONGhRs+p2c43
5V8uXPPwURcZ4GRR+jgoIS69IFBCWEfuXT7/F9TLZ8yQqReFT6Hy30u0EHbUQTTRczgy3brDD
HiI785QazCO7pTMo+sYiZosjKqfQi8EYuEo+bXjOO7i0sam9ij5wCqGF5liRLiDoC6Ky3FMMr
y+cutZD+oZp37fYWU0xwxVPMXte+7BQTFj8/Bn21ubj7cDCHmeUSdoex3Pftsx8dhiLZ+hlxi
SbuV9PG08Q51TbMSTxlcWPEOwrp9ZVNN001PZlaxaTp5aAoPXJbKgLt6YHmytknQ0ddI8hyNF
56XHdUIOX4GZ/K6H4K0idmuR8pP1sT2euUavaReJuRfWBy5z0MZWzXrcSGXB3O/A/AbIyguQe
LitdNaY1bv5DOwWbhJN3mF9dSrEqVdpRzUhu8gG6pxrWhL49cGs1sh+CUYkWf1XvTD+caBxMw
FPutFmwzOv1L4m5QVopP6+j8QH3/TwrQCf3ylaeVcockM=
X-Spam-Score: 2.9 (++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
has NOT identified this incoming email as spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
the administrator of that system for details.
Content preview: >> What is the "fixed order"? When I use C-x b, that buffer
becomes the >> one most recently shown in that window. > > The fixed order
is similar to how tabs work in web browsers. > It would be unexp [...]
Content analysis details: (2.9 points, 10.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
3.6 RCVD_IN_SBL_CSS RBL: Received via a relay in Spamhaus SBL-CSS
[213.142.97.35 listed in zen.spamhaus.org]
-0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at https://www.dnswl.org/,
low trust [212.227.17.22 listed in list.dnswl.org]
-0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2)
[212.227.17.22 listed in wl.mailspike.net]
-0.0 SPF_PASS SPF: sender matches SPF record
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail
provider (rudalics[at]gmx.at)
0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record
X-Debbugs-Envelope-To: 69993
Cc: 69993 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 1.9 (+)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
has NOT identified this incoming email as spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
the administrator of that system for details.
Content preview: >> What is the "fixed order"? When I use C-x b, that buffer
becomes the >> one most recently shown in that window. > > The fixed order
is similar to how tabs work in web browsers. > It would be unexp [...]
Content analysis details: (1.9 points, 10.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
-0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at https://www.dnswl.org/,
low trust
[212.227.17.22 listed in list.dnswl.org]
3.6 RCVD_IN_SBL_CSS RBL: Received via a relay in Spamhaus SBL-CSS
[213.142.97.35 listed in zen.spamhaus.org]
-0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2)
[212.227.17.22 listed in wl.mailspike.net]
-0.0 SPF_PASS SPF: sender matches SPF record
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail
provider (rudalics[at]gmx.at)
0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record
-1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list
manager
>> What is the "fixed order"? When I use C-x b, that buffer becomes the
>> one most recently shown in that window.
>
> The fixed order is similar to how tabs work in web browsers.
> It would be unexpected when switching to a tab will always
> move it to the end of the tab line. This is why it's unexpected
> for C-x b to move tabs when tab-line-mode is used.
But the lists of previous and next buffers have to reflect the order in
which these buffers were shown in a window. You probably can't map them
directly to tabs.
>> I think 'switch-to-prev-buffer-wrap' already confuses things. Wrapping,
>> for me, means to wrap around like when navigating on a ring of buffers.
>> Whether this should include buffers never shown in the window before is
>> a different issue IMO. And whether C-x b should change the order is yet
>> another issue. So maybe we need three options instead of one...
>
> I can't imagine why anyone would need wrapping when C-x C-left
> will visit hundreds of buffers never shown in the window.
Emacs "wrapped" in that case ever since (with at least two buffers).
> So we need only two options: wrapping buffers shown in the window,
> and to keep the fixed order of C-x b. So I will create a new request
> for the fixed order of C-x b. And here is the final patch for wrapping:
I still don't agree with it. IMHO we have to cater for two cases:
(1) The classic behavior where switching may show a buffer never shown
in the window before. I suppose you mean that
'switch-to-prev-buffer-wrap' does not affect it. If that's the
case, please say so.
(2) The new behavior where switching may only show buffers shown in that
window before. For this you want to either wrap or not. So the
option 'switch-to-prev-buffer-wrap' will affect (2) only. Right?
I think there's no clean way to provide one single option to choose
between (1) and (2) and whether to wrap.
martin
bug-gnu-emacs@HIDDEN:bug#69993; Package emacs.
Full text available.
Received: (at 69993) by debbugs.gnu.org; 28 Mar 2024 07:57:28 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Mar 28 03:57:28 2024
Received: from localhost ([127.0.0.1]:38952 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1rpkdb-0004OU-B2
for submit <at> debbugs.gnu.org; Thu, 28 Mar 2024 03:57:28 -0400
Received: from relay1-d.mail.gandi.net ([217.70.183.193]:60331)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <juri@HIDDEN>) id 1rpkdH-0004Ml-RH
for 69993 <at> debbugs.gnu.org; Thu, 28 Mar 2024 03:57:09 -0400
Received: by mail.gandi.net (Postfix) with ESMTPSA id 640A5240009;
Thu, 28 Mar 2024 07:57:00 +0000 (UTC)
From: Juri Linkov <juri@HIDDEN>
To: martin rudalics <rudalics@HIDDEN>
Subject: Re: bug#69993: Wrap window buffers while cycling
In-Reply-To: <5c71ea64-0f97-4b90-af61-1156fe33f1ea@HIDDEN> (martin rudalics's
message of "Wed, 27 Mar 2024 09:48:38 +0100")
Organization: LINKOV.NET
References: <86h6gug41x.fsf@HIDDEN>
<3419df35-1b96-4a64-8ed7-722a05c58742@HIDDEN>
<86le66ckhj.fsf@HIDDEN>
<c2258795-4352-46af-85d3-0a4f1ba3d261@HIDDEN>
<86h6gs2lk7.fsf@HIDDEN>
<5c71ea64-0f97-4b90-af61-1156fe33f1ea@HIDDEN>
Date: Thu, 28 Mar 2024 09:54:31 +0200
Message-ID: <86cyreu78w.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/30.0.50 (x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
X-GND-Sasl: juri@HIDDEN
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 69993
Cc: 69993 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)
--=-=-=
Content-Type: text/plain
>>> I'm not sure I understand. IIRC 'window-next-buffers' always returns
>>> nil unless you invoked 'switch-to-prev-buffer' before. It serves to
>>> "navigate" a window's buffer list, in particular, to "undo" preceding
>>> 'previous-buffer' calls when overshooting. 'switch-to-buffer' is not
>>> part of such a scenario.
>>
>> A new option should always keep the fixed order, even when users use C-x b
>> to visit a buffer that appeared in the window before.
>
> What is the "fixed order"? When I use C-x b, that buffer becomes the
> one most recently shown in that window.
The fixed order is similar to how tabs work in web browsers.
It would be unexpected when switching to a tab will always
move it to the end of the tab line. This is why it's unexpected
for C-x b to move tabs when tab-line-mode is used.
>> The problem is that there is no function that is called after
>> set-window-buffer to reset the order of prev/next-buffers.
>>
>> set-window-buffer works that way that before changing the window buffer
>> it calls record-window-buffer. But record-window-buffer has
>> no information about new-buffer. So it can't reorder prev/next-buffers
>> based on new-buffer that will be displayed in this window.
>>
>> Then later set-window-buffer sets window's buffer,
>> but after that it doesn't call any function like
>> record-window-buffer that could reorder prev/next-buffers.
>>
>> Then maybe possible to add such reordering after calling
>> set-window-buffer? I mean such places as after calling
>> set-window-buffer in window--display-buffer, and after calling
>> set-window-buffer in switch-to-buffer.
>
> Then give 'record-window-buffer' a second argument - the new buffer to
> be shown. I'm a bit reluctant to work in this area - the introduction
> of 'push-window-buffer-onto-prev' has obfuscated the code considerably
> for no apparent use (at least one that I could understand).
Ok, let's add a second argument to 'record-window-buffer'.
I'll do this in a separate feature request for a new option
that will keep the fixed order for C-x b
since it's quite different from the wrapping option.
> I see no problems with it. After C-x b *foo* I want to return to *foo*
> via 'previous-buffer' after switching to *bar* via a second C-x b. What
> would you want to see instead? Maybe I still misunderstand you.
Selecting a buffer via C-x b still uses the sorting order of buffers
by the most-recently-used. So after C-x b *bar* you still can easily
return to *foo* by C-x b RET. But the proposed change makes sense
when using tab-line-mode where C-x b messes up buffer tabs.
> I think 'switch-to-prev-buffer-wrap' already confuses things. Wrapping,
> for me, means to wrap around like when navigating on a ring of buffers.
> Whether this should include buffers never shown in the window before is
> a different issue IMO. And whether C-x b should change the order is yet
> another issue. So maybe we need three options instead of one...
I can't imagine why anyone would need wrapping when C-x C-left
will visit hundreds of buffers never shown in the window.
So we need only two options: wrapping buffers shown in the window,
and to keep the fixed order of C-x b. So I will create a new request
for the fixed order of C-x b. And here is the final patch for wrapping:
--=-=-=
Content-Type: text/x-diff
Content-Disposition: inline; filename=switch-to-prev-buffer-wrap.patch
diff --git a/lisp/window.el b/lisp/window.el
index df55a7ca673..ff08b0bcfc9 100644
--- a/lisp/window.el
+++ b/lisp/window.el
@@ -4542,6 +4546,22 @@ set-window-buffer-start-and-point
(when point
(set-window-point window point))))
+(defcustom switch-to-prev-buffer-wrap nil
+ "Wrap to the first or last window buffer while cycling.
+The value t means wrapping around while cycling buffers appeared in the
+window before. So when the commands that switch buffers in the selected
+window `previous-buffer' and `next-buffer' reach the first or the last
+buffer (these buffers are visible when using `tab-line-mode'),
+then wrap around to another end of the list of previous/next buffers.
+
+When the value is `stop', stop at the first or last buffer
+in the list of previous/next buffers, but don't wrap around."
+ :type '(choice (const :tag "Never wrap" nil)
+ (const :tag "Stop at window-local buffers" stop)
+ (const :tag "Wrap to window-local buffers" t))
+ :version "30.1"
+ :group 'windows)
+
(defcustom switch-to-visible-buffer t
"If non-nil, allow switching to an already visible buffer.
If this variable is non-nil, `switch-to-prev-buffer' and
@@ -4676,7 +4696,7 @@ switch-to-prev-buffer
((or switch-to-prev-buffer-skip
(not switch-to-visible-buffer))
frame)))
- entry new-buffer killed-buffers skipped)
+ entry new-buffer killed-buffers skipped wrapped)
(when (window-minibuffer-p window)
;; Don't switch in minibuffer window.
(unless (setq window (minibuffer-selected-window))
@@ -4710,8 +4730,8 @@ switch-to-prev-buffer
;; a buried buffer instead. Otherwise, we must reverse the global
;; buffer list in order to make sure that switching to the
;; previous/next buffer traverse it in opposite directions. Skip
- ;; this step for side windows.
- (unless window-side
+ ;; this step for side windows or when wrapping.
+ (unless (or window-side switch-to-prev-buffer-wrap)
(dolist (buffer (if bury-or-kill
(buffer-list frame)
(nreverse (buffer-list frame))))
@@ -4729,7 +4749,9 @@ switch-to-prev-buffer
(set-window-buffer-start-and-point window new-buffer)
(throw 'found t)))))
- (unless bury-or-kill
+ (when (eq switch-to-prev-buffer-wrap 'stop)
+ (setq wrapped 'stop))
+ (unless (or bury-or-kill (eq switch-to-prev-buffer-wrap 'stop))
;; Scan reverted next buffers last (must not use nreverse
;; here!).
(dolist (buffer (reverse next-buffers))
@@ -4743,12 +4765,13 @@ switch-to-prev-buffer
(setq entry (assq buffer (window-prev-buffers window))))
(if (switch-to-prev-buffer-skip-p skip window buffer bury-or-kill)
(setq skipped (or skipped buffer))
- (setq new-buffer buffer)
+ (setq new-buffer buffer wrapped t)
(set-window-buffer-start-and-point
window new-buffer (nth 1 entry) (nth 2 entry))
(throw 'found t)))))
- (when (and skipped (not (functionp switch-to-prev-buffer-skip)))
+ (when (and skipped (not (functionp switch-to-prev-buffer-skip))
+ (not wrapped))
;; Show first skipped buffer, unless skip was a function.
(setq new-buffer skipped)
(set-window-buffer-start-and-point window new-buffer)))
@@ -4768,10 +4791,28 @@ switch-to-prev-buffer
;; it.
(set-window-prev-buffers
window (append (window-prev-buffers window) (list entry)))))
- ;; Move `old-buffer' to head of WINDOW's restored list of next
- ;; buffers.
- (set-window-next-buffers
- window (cons old-buffer (delq old-buffer next-buffers))))
+ (if (not (and switch-to-prev-buffer-wrap wrapped))
+ ;; Move `old-buffer' to head of WINDOW's restored list of next
+ ;; buffers.
+ (set-window-next-buffers
+ window (cons old-buffer (delq old-buffer next-buffers)))
+ (if (eq wrapped 'stop)
+ (setq new-buffer nil)
+ ;; Restore the right order of previous buffers.
+ (let ((prev-buffers (window-prev-buffers window)))
+ ;; Use the same sorting order as was in next-buffers
+ ;; with old-buffer at the bottom.
+ (setq prev-buffers
+ (sort prev-buffers
+ (lambda (a b)
+ (cond
+ ((eq (car a) old-buffer) nil)
+ ((eq (car b) old-buffer) t)
+ (t (< (length (memq (car a) next-buffers))
+ (length (memq (car b) next-buffers))))))))
+ (set-window-prev-buffers window prev-buffers)
+ ;; When record-window-buffer doesn't reset next-buffers.
+ (set-window-next-buffers window nil)))))
;; Remove killed buffers from WINDOW's previous and next buffers.
(when killed-buffers
@@ -4812,7 +4853,7 @@ switch-to-next-buffer
((or switch-to-prev-buffer-skip
(not switch-to-visible-buffer))
frame)))
- new-buffer entry killed-buffers skipped)
+ new-buffer entry killed-buffers skipped wrapped)
(when (window-minibuffer-p window)
;; Don't switch in minibuffer window.
(unless (setq window (minibuffer-selected-window))
@@ -4839,7 +4880,7 @@ switch-to-next-buffer
(throw 'found t))))
;; Scan the buffer list of WINDOW's frame next, skipping previous
;; buffers entries. Skip this step for side windows.
- (unless window-side
+ (unless (or window-side switch-to-prev-buffer-wrap)
(dolist (buffer (buffer-list frame))
(when (and (buffer-live-p buffer)
(not (eq buffer old-buffer))
@@ -4856,27 +4897,38 @@ switch-to-next-buffer
(throw 'found t)))))
;; Scan WINDOW's reverted previous buffers last (must not use
;; nreverse here!)
- (dolist (entry (reverse (window-prev-buffers window)))
- (when (and (not (eq new-buffer (car entry)))
- (not (eq old-buffer (car entry)))
- (setq new-buffer (car entry))
- (or (buffer-live-p new-buffer)
- (not (setq killed-buffers
- (cons new-buffer killed-buffers))))
- (or (null pred) (funcall pred new-buffer)))
- (if (switch-to-prev-buffer-skip-p skip window new-buffer)
- (setq skipped (or skipped new-buffer))
- (set-window-buffer-start-and-point
- window new-buffer (nth 1 entry) (nth 2 entry))
- (throw 'found t))))
+ (if (eq switch-to-prev-buffer-wrap 'stop)
+ (setq wrapped 'stop)
+ (dolist (entry (reverse (window-prev-buffers window)))
+ (when (and (not (eq new-buffer (car entry)))
+ (not (eq old-buffer (car entry)))
+ (setq new-buffer (car entry))
+ (or (buffer-live-p new-buffer)
+ (not (setq killed-buffers
+ (cons new-buffer killed-buffers))))
+ (or (null pred) (funcall pred new-buffer)))
+ (if (switch-to-prev-buffer-skip-p skip window new-buffer)
+ (setq skipped (or skipped new-buffer))
+ (setq wrapped t)
+ (set-window-buffer-start-and-point
+ window new-buffer (nth 1 entry) (nth 2 entry))
+ (throw 'found t)))))
- (when (and skipped (not (functionp switch-to-prev-buffer-skip)))
+ (when (and skipped (not (functionp switch-to-prev-buffer-skip))
+ (not wrapped))
;; Show first skipped buffer, unless skip was a function.
(setq new-buffer skipped)
(set-window-buffer-start-and-point window new-buffer)))
- ;; Remove `new-buffer' from and restore WINDOW's next buffers.
- (set-window-next-buffers window (delq new-buffer next-buffers))
+ (if (not (and switch-to-prev-buffer-wrap wrapped))
+ ;; Remove `new-buffer' from and restore WINDOW's next buffers.
+ (set-window-next-buffers window (delq new-buffer next-buffers))
+ (if (eq wrapped 'stop)
+ (setq new-buffer nil)
+ (let ((prev-buffers (window-prev-buffers window)))
+ (setq prev-buffers
+ (nreverse (delq new-buffer (mapcar #'car prev-buffers))))
+ (set-window-next-buffers window prev-buffers))))
;; Remove killed buffers from WINDOW's previous and next buffers.
(when killed-buffers
--=-=-=--
bug-gnu-emacs@HIDDEN:bug#69993; Package emacs.
Full text available.
Received: (at 69993) by debbugs.gnu.org; 27 Mar 2024 08:48:53 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Mar 27 04:48:53 2024
Received: from localhost ([127.0.0.1]:35743 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1rpOxn-000565-G7
for submit <at> debbugs.gnu.org; Wed, 27 Mar 2024 04:48:53 -0400
Received: from mout.gmx.net ([212.227.17.22]:33899)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <rudalics@HIDDEN>) id 1rpOxj-00052k-8K
for 69993 <at> debbugs.gnu.org; Wed, 27 Mar 2024 04:48:49 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.at;
s=s31663417; t=1711529319; x=1712134119; i=rudalics@HIDDEN;
bh=DQfyjcesOJ9Viv5IbfbIQXd7Lfri3iOlSsG6J7/j5sY=;
h=X-UI-Sender-Class:Date:Subject:To:Cc:References:From:
In-Reply-To;
b=LyAVqNbPT6f13FcXx16CR2y36KA/e6uxMStLp2j4KziE+062+fZ+urt54NoxPv0m
/Uegg2Za0r3hT61KPsH7U8INwD7yFBUIerKblnWZdI/IT8JO0EJxD1Nxm8ZluEDxj
ndh0yNMyCkFho96iD7mtwJTfIeaH4TBRilxxbCDo1xCdLc0xLOIuyTmrjOpqUHXvB
NyQKhf/Wcx9NEFmus9c73bEwCFkioidWdNKvHBD/AgXtfvKUWja1/3iiOxKV7mu5C
tG5JxM03D93VOFP94kIELxoZAmdlKAD8dtiqtxsFe0285oUAS2nXKm2/sctyfpTUQ
V0vthN0lb2b6Yp8TqQ==
X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a
Received: from [192.168.31.113] ([212.95.5.92]) by mail.gmx.net (mrgmx105
[212.227.17.168]) with ESMTPSA (Nemesis) id 1MEm27-1s3z9I0JrP-00GGUG; Wed, 27
Mar 2024 09:48:39 +0100
Message-ID: <5c71ea64-0f97-4b90-af61-1156fe33f1ea@HIDDEN>
Date: Wed, 27 Mar 2024 09:48:38 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: bug#69993: Wrap window buffers while cycling
To: Juri Linkov <juri@HIDDEN>
References: <86h6gug41x.fsf@HIDDEN>
<3419df35-1b96-4a64-8ed7-722a05c58742@HIDDEN>
<86le66ckhj.fsf@HIDDEN>
<c2258795-4352-46af-85d3-0a4f1ba3d261@HIDDEN>
<86h6gs2lk7.fsf@HIDDEN>
Content-Language: en-US
From: martin rudalics <rudalics@HIDDEN>
In-Reply-To: <86h6gs2lk7.fsf@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K1:GVnGB2IuUohF0BX38bmduwftTyFi3jBXDlFn5tZLtIQrDyI3mZS
32OABYiLnrIZD0UkPlBlTmSJOo5k/BIxUSfSMOl134jJtXaphAoeZs+FvDhOiauU7dCnCua
sG13o4P5HDlmJhF8Y728OK5ncUunbRbSeNRLZARGP6uyoJu8zSWUM9nWETNiEJSOa2a4xwd
XK/4ywGMIuR5zqgMzXLjQ==
X-Spam-Flag: NO
UI-OutboundReport: notjunk:1;M01:P0:Kjn5xYutXc8=;0hIH7Vrmgr6Duwf6R8TZLmbfBgz
ML7d3oZUO1t45Pc5qjzUpjLvwiOLGZNDIST6u/q/d1cwn7Qz0dPl0mdLGLYOLKsyF+8L35ETp
9O96RmVLfV6XreTlT6clid68CbDymN8cD4aYouDGGoMqnXHa01COraSctHTbRBURA5kcH8I8l
wAzFux7mx/hQji+QbMfRMWn9e+/bSl10D/CaB1kH8r+sd2BQ26N7rw1FB0QcAolNhXg1fa1uu
azf6kv6dUdUNZz9t1l3LWqarip7ngXPeufhrmw06iRjKAGqi/Cw+XXVqiviLm5TUqyxV4bdZZ
KRXX0aurCjrAZQVS1KBIaTT389D1TwW4HHfZlO/KAGAoCXDfbemDmqh2jdcpsxu9wNwr0GJYB
X91F/YD2P8T6DqKQibLZfAiN86ISDDK9onASVulZJ8tDDBp3vNbOIbgVEv4pZJX0xUc3EcIm6
1nyA7XLJ4S5Z7aX2sNM25CVUnkNQNBzPBbW1s9Y1DBYfJD6GGf23/5gvZrKO4ur9p4xqYaR1m
8oEwMc4pM1uj58TsH6dOW6gz/rY/YbwQFZP++uBy0VVC0yAdKuA3RqoJyAww6orFYqXvPNoi8
ppecoeww7rizBQwPP5YPzKsOtzuCQ0QAKH7WGOqK7qfZrnMB19/8dgQTkcD/B2ZxceEuNFAxL
z0WWVJZPAlWD3NBHXH6fXENGzyUvt5Y/gPbMHSS+V8mjCgB2Q8joQRP3/1KHzwHwK6CfLJE8Z
4mjCIVR71ng0VzQkcpzVwGgyj0bGz/jiMbjTRTfFMRPwKboao5ue5Slf6ExEi8QqvxOnCVhQC
Pu7tdzhbwOC2w3eoU4iLYxIHePUV6qAxBZRIUwKmO521ukLcH+uwtOhHyfFzxQU6Yp
X-Spam-Score: 2.9 (++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
has NOT identified this incoming email as spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
the administrator of that system for details.
Content preview: >> I'm not sure I understand. IIRC 'window-next-buffers'
always returns >> nil unless you invoked 'switch-to-prev-buffer' before. It
serves to >> "navigate" a window's buffer list, in particular, to [...]
Content analysis details: (2.9 points, 10.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
3.6 RCVD_IN_SBL_CSS RBL: Received via a relay in Spamhaus SBL-CSS
[212.95.5.92 listed in zen.spamhaus.org]
-0.0 SPF_PASS SPF: sender matches SPF record
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail
provider (rudalics[at]gmx.at)
0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record
-0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at https://www.dnswl.org/,
low trust [212.227.17.22 listed in list.dnswl.org]
-0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2)
[212.227.17.22 listed in wl.mailspike.net]
X-Debbugs-Envelope-To: 69993
Cc: 69993 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 1.9 (+)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
has NOT identified this incoming email as spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
the administrator of that system for details.
Content preview: >> I'm not sure I understand. IIRC 'window-next-buffers'
always returns >> nil unless you invoked 'switch-to-prev-buffer' before. It
serves to >> "navigate" a window's buffer list, in particular, to [...]
Content analysis details: (1.9 points, 10.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
-0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at https://www.dnswl.org/,
low trust
[212.227.17.22 listed in list.dnswl.org]
3.6 RCVD_IN_SBL_CSS RBL: Received via a relay in Spamhaus SBL-CSS
[212.95.5.92 listed in zen.spamhaus.org]
-0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2)
[212.227.17.22 listed in wl.mailspike.net]
-0.0 SPF_PASS SPF: sender matches SPF record
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail
provider (rudalics[at]gmx.at)
0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record
-1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list
manager
>> I'm not sure I understand. IIRC 'window-next-buffers' always returns
>> nil unless you invoked 'switch-to-prev-buffer' before. It serves to
>> "navigate" a window's buffer list, in particular, to "undo" preceding
>> 'previous-buffer' calls when overshooting. 'switch-to-buffer' is not
>> part of such a scenario.
>
> A new option should always keep the fixed order, even when users use C-x b
> to visit a buffer that appeared in the window before.
What is the "fixed order"? When I use C-x b, that buffer becomes the
one most recently shown in that window.
> The problem is that there is no function that is called after
> set-window-buffer to reset the order of prev/next-buffers.
>
> set-window-buffer works that way that before changing the window buffer
> it calls record-window-buffer. But record-window-buffer has
> no information about new-buffer. So it can't reorder prev/next-buffers
> based on new-buffer that will be displayed in this window.
>
> Then later set-window-buffer sets window's buffer,
> but after that it doesn't call any function like
> record-window-buffer that could reorder prev/next-buffers.
>
> Then maybe possible to add such reordering after calling
> set-window-buffer? I mean such places as after calling
> set-window-buffer in window--display-buffer, and after calling
> set-window-buffer in switch-to-buffer.
Then give 'record-window-buffer' a second argument - the new buffer to
be shown. I'm a bit reluctant to work in this area - the introduction
of 'push-window-buffer-onto-prev' has obfuscated the code considerably
for no apparent use (at least one that I could understand).
> Ok, here is the current patch that supports the fixed order
> for 'C-x C-left' and 'C-x C-right' but still not for 'C-x b':
I see no problems with it. After C-x b *foo* I want to return to *foo*
via 'previous-buffer' after switching to *bar* via a second C-x b. What
would you want to see instead? Maybe I still misunderstand you.
I think 'switch-to-prev-buffer-wrap' already confuses things. Wrapping,
for me, means to wrap around like when navigating on a ring of buffers.
Whether this should include buffers never shown in the window before is
a different issue IMO. And whether C-x b should change the order is yet
another issue. So maybe we need three options instead of one...
martin
bug-gnu-emacs@HIDDEN:bug#69993; Package emacs.
Full text available.
Received: (at 69993) by debbugs.gnu.org; 27 Mar 2024 07:21:09 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Mar 27 03:21:09 2024
Received: from localhost ([127.0.0.1]:35645 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1rpNau-0007CK-Jx
for submit <at> debbugs.gnu.org; Wed, 27 Mar 2024 03:21:09 -0400
Received: from relay3-d.mail.gandi.net ([2001:4b98:dc4:8::223]:33019)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <juri@HIDDEN>) id 1rpNam-0007A4-8S
for 69993 <at> debbugs.gnu.org; Wed, 27 Mar 2024 03:21:01 -0400
Received: by mail.gandi.net (Postfix) with ESMTPSA id 7FE6560004;
Wed, 27 Mar 2024 07:20:52 +0000 (UTC)
From: Juri Linkov <juri@HIDDEN>
To: martin rudalics <rudalics@HIDDEN>
Subject: Re: bug#69993: Wrap window buffers while cycling
In-Reply-To: <c2258795-4352-46af-85d3-0a4f1ba3d261@HIDDEN> (martin rudalics's
message of "Tue, 26 Mar 2024 10:56:24 +0100")
Organization: LINKOV.NET
References: <86h6gug41x.fsf@HIDDEN>
<3419df35-1b96-4a64-8ed7-722a05c58742@HIDDEN>
<86le66ckhj.fsf@HIDDEN>
<c2258795-4352-46af-85d3-0a4f1ba3d261@HIDDEN>
Date: Wed, 27 Mar 2024 09:20:32 +0200
Message-ID: <86h6gs2lk7.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/30.0.50 (x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
X-GND-Sasl: juri@HIDDEN
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 69993
Cc: 69993 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)
--=-=-=
Content-Type: text/plain
>> There is a remaining problem, and I can't find a way to fix it.
>> When a buffer already appeared in the window before,
>> then switching to that buffer with e.g. 'C-x b'
>> moves it to the end of the list. Technically
>> this means that window-next-buffers is set to nil.
>
> I'm not sure I understand. IIRC 'window-next-buffers' always returns
> nil unless you invoked 'switch-to-prev-buffer' before. It serves to
> "navigate" a window's buffer list, in particular, to "undo" preceding
> 'previous-buffer' calls when overshooting. 'switch-to-buffer' is not
> part of such a scenario.
A new option should always keep the fixed order, even when users use C-x b
to visit a buffer that appeared in the window before.
The problem is that there is no function that is called after
set-window-buffer to reset the order of prev/next-buffers.
set-window-buffer works that way that before changing the window buffer
it calls record-window-buffer. But record-window-buffer has
no information about new-buffer. So it can't reorder prev/next-buffers
based on new-buffer that will be displayed in this window.
Then later set-window-buffer sets window's buffer,
but after that it doesn't call any function like
record-window-buffer that could reorder prev/next-buffers.
Then maybe possible to add such reordering after calling
set-window-buffer? I mean such places as after calling
set-window-buffer in window--display-buffer, and after calling
set-window-buffer in switch-to-buffer.
>> However, I can't find code that does this. Could you help
>> to find it? I already found one occurrence of
>> (set-window-next-buffers window nil) in record-window-buffer.
>> But after adding a condition with switch-to-prev-buffer-wrap
>> it still moves the switched buffer to the end.
>
> If you get me the patch you currently use and a scenario, I'll try.
Ok, here is the current patch that supports the fixed order
for 'C-x C-left' and 'C-x C-right' but still not for 'C-x b':
--=-=-=
Content-Type: text/x-diff
Content-Disposition: inline; filename=switch-to-prev-buffer-wrap.patch
diff --git a/lisp/window.el b/lisp/window.el
index df55a7ca673..5fc346571a8 100644
--- a/lisp/window.el
+++ b/lisp/window.el
@@ -4475,24 +4475,26 @@ push-window-buffer-onto-prev
(let* ((window (window-normalize-window window t))
(buffer (window-buffer window))
(w-list (window-prev-buffers window))
- (entry (assq buffer w-list)))
- (when entry
- (setq w-list (assq-delete-all buffer w-list)))
- (let ((start (window-start window))
- (point (window-point window)))
- (setq entry
- (cons buffer
- (with-current-buffer buffer
- (if entry
- ;; We have an entry, update marker positions.
- (list (set-marker (nth 1 entry) start)
- (set-marker (nth 2 entry) point))
- (list (copy-marker start)
- (copy-marker
- ;; Preserve window-point-insertion-type
- ;; (Bug#12855)
- point window-point-insertion-type))))))
- (set-window-prev-buffers window (cons entry w-list)))))
+ (entry (assq buffer w-list))
+ (start (window-start window))
+ (point (window-point window))
+ (start-point
+ (with-current-buffer buffer
+ (if entry
+ ;; We have an entry, update marker positions.
+ (list (set-marker (nth 1 entry) start)
+ (set-marker (nth 2 entry) point))
+ (list (copy-marker start)
+ (copy-marker
+ ;; Preserve window-point-insertion-type
+ ;; (Bug#12855)
+ point window-point-insertion-type))))))
+ (if (and switch-to-prev-buffer-wrap entry)
+ (setf (alist-get buffer w-list) start-point)
+ (when entry
+ (setq w-list (assq-delete-all buffer w-list)))
+ (set-window-prev-buffers
+ window (cons (cons buffer start-point) w-list)))))
(defun record-window-buffer (&optional window)
"Record WINDOW's buffer.
@@ -4501,7 +4503,9 @@ record-window-buffer
(buffer (window-buffer window)))
;; Reset WINDOW's next buffers. If needed, they are resurrected by
;; `switch-to-prev-buffer' and `switch-to-next-buffer'.
- (set-window-next-buffers window nil)
+ (unless (and switch-to-prev-buffer-wrap
+ (assq buffer (window-prev-buffers window)))
+ (set-window-next-buffers window nil))
;; Don't record insignificant buffers.
(when (not (eq (aref (buffer-name buffer) 0) ?\s))
@@ -4542,6 +4546,16 @@ set-window-buffer-start-and-point
(when point
(set-window-point window point))))
+(defcustom switch-to-prev-buffer-wrap nil
+ "Wrap to the first/last window-local buffer while cycling.
+When t, wrap to the first/last buffer.
+When the value is `stop', stop at the first/last buffer."
+ :type '(choice (const :tag "Never wrap" nil)
+ (const :tag "Stop at window-local buffers" stop)
+ (const :tag "Wrap to window-local buffers" t))
+ :version "30.1"
+ :group 'windows)
+
(defcustom switch-to-visible-buffer t
"If non-nil, allow switching to an already visible buffer.
If this variable is non-nil, `switch-to-prev-buffer' and
@@ -4676,7 +4690,7 @@ switch-to-prev-buffer
((or switch-to-prev-buffer-skip
(not switch-to-visible-buffer))
frame)))
- entry new-buffer killed-buffers skipped)
+ entry new-buffer killed-buffers skipped wrapped)
(when (window-minibuffer-p window)
;; Don't switch in minibuffer window.
(unless (setq window (minibuffer-selected-window))
@@ -4710,8 +4724,8 @@ switch-to-prev-buffer
;; a buried buffer instead. Otherwise, we must reverse the global
;; buffer list in order to make sure that switching to the
;; previous/next buffer traverse it in opposite directions. Skip
- ;; this step for side windows.
- (unless window-side
+ ;; this step for side windows or when wrapping.
+ (unless (or window-side switch-to-prev-buffer-wrap)
(dolist (buffer (if bury-or-kill
(buffer-list frame)
(nreverse (buffer-list frame))))
@@ -4729,7 +4743,9 @@ switch-to-prev-buffer
(set-window-buffer-start-and-point window new-buffer)
(throw 'found t)))))
- (unless bury-or-kill
+ (when (eq switch-to-prev-buffer-wrap 'stop)
+ (setq wrapped 'stop))
+ (unless (or bury-or-kill (eq switch-to-prev-buffer-wrap 'stop))
;; Scan reverted next buffers last (must not use nreverse
;; here!).
(dolist (buffer (reverse next-buffers))
@@ -4743,12 +4759,13 @@ switch-to-prev-buffer
(setq entry (assq buffer (window-prev-buffers window))))
(if (switch-to-prev-buffer-skip-p skip window buffer bury-or-kill)
(setq skipped (or skipped buffer))
- (setq new-buffer buffer)
+ (setq new-buffer buffer wrapped t)
(set-window-buffer-start-and-point
window new-buffer (nth 1 entry) (nth 2 entry))
(throw 'found t)))))
- (when (and skipped (not (functionp switch-to-prev-buffer-skip)))
+ (when (and skipped (not (functionp switch-to-prev-buffer-skip))
+ (not wrapped))
;; Show first skipped buffer, unless skip was a function.
(setq new-buffer skipped)
(set-window-buffer-start-and-point window new-buffer)))
@@ -4768,10 +4785,28 @@ switch-to-prev-buffer
;; it.
(set-window-prev-buffers
window (append (window-prev-buffers window) (list entry)))))
- ;; Move `old-buffer' to head of WINDOW's restored list of next
- ;; buffers.
- (set-window-next-buffers
- window (cons old-buffer (delq old-buffer next-buffers))))
+ (if (not (and switch-to-prev-buffer-wrap wrapped))
+ ;; Move `old-buffer' to head of WINDOW's restored list of next
+ ;; buffers.
+ (set-window-next-buffers
+ window (cons old-buffer (delq old-buffer next-buffers)))
+ (if (eq wrapped 'stop)
+ (setq new-buffer nil)
+ ;; Restore the right order of previous buffers.
+ (let ((prev-buffers (window-prev-buffers window)))
+ ;; Use the same sorting order as was in next-buffers
+ ;; with old-buffer at the bottom.
+ (setq prev-buffers
+ (sort prev-buffers
+ (lambda (a b)
+ (cond
+ ((eq (car a) old-buffer) nil)
+ ((eq (car b) old-buffer) t)
+ (t (< (length (memq (car a) next-buffers))
+ (length (memq (car b) next-buffers))))))))
+ (set-window-prev-buffers window prev-buffers)
+ ;; When record-window-buffer doesn't reset next-buffers.
+ (set-window-next-buffers window nil)))))
;; Remove killed buffers from WINDOW's previous and next buffers.
(when killed-buffers
@@ -4812,7 +4847,7 @@ switch-to-next-buffer
((or switch-to-prev-buffer-skip
(not switch-to-visible-buffer))
frame)))
- new-buffer entry killed-buffers skipped)
+ new-buffer entry killed-buffers skipped wrapped)
(when (window-minibuffer-p window)
;; Don't switch in minibuffer window.
(unless (setq window (minibuffer-selected-window))
@@ -4839,7 +4874,7 @@ switch-to-next-buffer
(throw 'found t))))
;; Scan the buffer list of WINDOW's frame next, skipping previous
;; buffers entries. Skip this step for side windows.
- (unless window-side
+ (unless (or window-side switch-to-prev-buffer-wrap)
(dolist (buffer (buffer-list frame))
(when (and (buffer-live-p buffer)
(not (eq buffer old-buffer))
@@ -4856,27 +4891,38 @@ switch-to-next-buffer
(throw 'found t)))))
;; Scan WINDOW's reverted previous buffers last (must not use
;; nreverse here!)
- (dolist (entry (reverse (window-prev-buffers window)))
- (when (and (not (eq new-buffer (car entry)))
- (not (eq old-buffer (car entry)))
- (setq new-buffer (car entry))
- (or (buffer-live-p new-buffer)
- (not (setq killed-buffers
- (cons new-buffer killed-buffers))))
- (or (null pred) (funcall pred new-buffer)))
- (if (switch-to-prev-buffer-skip-p skip window new-buffer)
- (setq skipped (or skipped new-buffer))
- (set-window-buffer-start-and-point
- window new-buffer (nth 1 entry) (nth 2 entry))
- (throw 'found t))))
+ (if (eq switch-to-prev-buffer-wrap 'stop)
+ (setq wrapped 'stop)
+ (dolist (entry (reverse (window-prev-buffers window)))
+ (when (and (not (eq new-buffer (car entry)))
+ (not (eq old-buffer (car entry)))
+ (setq new-buffer (car entry))
+ (or (buffer-live-p new-buffer)
+ (not (setq killed-buffers
+ (cons new-buffer killed-buffers))))
+ (or (null pred) (funcall pred new-buffer)))
+ (if (switch-to-prev-buffer-skip-p skip window new-buffer)
+ (setq skipped (or skipped new-buffer))
+ (setq wrapped t)
+ (set-window-buffer-start-and-point
+ window new-buffer (nth 1 entry) (nth 2 entry))
+ (throw 'found t)))))
- (when (and skipped (not (functionp switch-to-prev-buffer-skip)))
+ (when (and skipped (not (functionp switch-to-prev-buffer-skip))
+ (not wrapped))
;; Show first skipped buffer, unless skip was a function.
(setq new-buffer skipped)
(set-window-buffer-start-and-point window new-buffer)))
- ;; Remove `new-buffer' from and restore WINDOW's next buffers.
- (set-window-next-buffers window (delq new-buffer next-buffers))
+ (if (not (and switch-to-prev-buffer-wrap wrapped))
+ ;; Remove `new-buffer' from and restore WINDOW's next buffers.
+ (set-window-next-buffers window (delq new-buffer next-buffers))
+ (if (eq wrapped 'stop)
+ (setq new-buffer nil)
+ (let ((prev-buffers (window-prev-buffers window)))
+ (setq prev-buffers
+ (nreverse (delq new-buffer (mapcar #'car prev-buffers))))
+ (set-window-next-buffers window prev-buffers))))
;; Remove killed buffers from WINDOW's previous and next buffers.
(when killed-buffers
--=-=-=--
bug-gnu-emacs@HIDDEN:bug#69993; Package emacs.
Full text available.
Received: (at 69993) by debbugs.gnu.org; 26 Mar 2024 14:06:03 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Mar 26 10:06:03 2024
Received: from localhost ([127.0.0.1]:34384 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1rp7RC-0004b9-U4
for submit <at> debbugs.gnu.org; Tue, 26 Mar 2024 10:06:03 -0400
Received: from mout.gmx.net ([212.227.17.22]:60409)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <rudalics@HIDDEN>) id 1rp7RA-0004aF-7d
for 69993 <at> debbugs.gnu.org; Tue, 26 Mar 2024 10:06:01 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.at;
s=s31663417; t=1711461955; x=1712066755; i=rudalics@HIDDEN;
bh=mFCASXaiCwk0KW+geSBWILVkRz7+HU7v6E/KynmNDMU=;
h=X-UI-Sender-Class:Date:Subject:To:Cc:References:From:
In-Reply-To;
b=hxFlAaIQ4MYf6eEe/Uo6MCHUvJnzNcFCUfCosquM/6YpE2g/xOUwFw7MBSfC5KsY
FMB/leBcJc88AKbI+8qJm/P8VCDxMfRKPEBf+ufKwKQ4IUxi3r/5PIpUMFEp1Knlt
5PG3fiS1387wp66CC2xVAHl/gpRtC2bfhpS7pdC60Ot3t6BvjXJTFaQA1T/p/K3eI
mNEqLPbFaSpYahlWkqPSML1oSyKxuwJD92BnZe0seCcsctY0SDm25dVHVdO0LEBkE
0HhFueAm5gZX4lntoXTrxw3cwy4vvZN/UKtNswSwA+JLxlolh2uXWCZvWaYvtftS1
ZZHUQmm7P/4HTZarlQ==
X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a
Received: from [192.168.31.113] ([213.142.96.219]) by mail.gmx.net (mrgmx105
[212.227.17.168]) with ESMTPSA (Nemesis) id 1Mw9UK-1sgt5B2PMS-00s8Pr; Tue, 26
Mar 2024 10:56:25 +0100
Message-ID: <c2258795-4352-46af-85d3-0a4f1ba3d261@HIDDEN>
Date: Tue, 26 Mar 2024 10:56:24 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: bug#69993: Wrap window buffers while cycling
To: Juri Linkov <juri@HIDDEN>
References: <86h6gug41x.fsf@HIDDEN>
<3419df35-1b96-4a64-8ed7-722a05c58742@HIDDEN>
<86le66ckhj.fsf@HIDDEN>
Content-Language: en-US
From: martin rudalics <rudalics@HIDDEN>
In-Reply-To: <86le66ckhj.fsf@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K1:5XWIq1tBWRBXPYgIvCqzT4/hsB669ghY9MpKp2MDDb9PmqdQ0oJ
of2MNhDXtg5pDbchJQhcCxK6kECcdDuJiQl8xaadwrJlt2SVn0MgUUlwQaxR5iIY6dlqy8W
XTKS6YqNF7hEXXNxHjtX2LNFpfbBfwN0os+fRnd2wxBq26qHJkHE2Tts37LesqYMV1oJtlX
bfzzQ3OA4O4AkRbPVRgCw==
X-Spam-Flag: NO
UI-OutboundReport: notjunk:1;M01:P0:QmLjRnjzH8w=;0bIdJy5qTPkU+uUcmWOdTJd2oZ4
G6FXv2oXgEjG28knCPncCBZA/DN8Z/dLc3JQescQ9eyz9Jb2UHD4IhaGCA97q8o8KjGaYeEkg
T+fWbxy02m75kCH3eiiAyHs9gGGtAhkoqFJt+NLXgJ+lzBMTqW2kdRv8h2zlT9tiW45j+trx7
wLF1n81HyLLxiLIUHMKFN0S/62CpFA7sFcP086Uk/wI9CoS4tc6hxjrfyE/AZ3h7TxxlzmoFA
50mN1On+CInJbRUCdPEuY4t/CsJ7hue02kZtTmKx5gGpojuqkuJQTBv7H+5QcHb15Yp9qBXvO
/M4/rHH0/I6hyqkjVoe/ecDFYlLi1LEfLQxHNC4IhLKHfk0j668KwnfTEAiDxbY+/mVFqes1n
p4qsYt+hRx3PUH52PKbEUq14owNeEx4mISa6u/qJ3jH33Lfz9aoi0y9F7bFP4kKNY1RMlGrbz
1EmG3ayX/6jUnewm+ZAp1MYbLFUEYIK5r8F2d3ppmnH5fFNccApr0iVDmT2hA/SLN4MSML6Do
yp7o46PYNjzDi1Hg+1LJbq9TerPuktyv6TggTpgpC8HpT/Vr0C8zXp/+Mq7n31xwiLttwEOM0
OChsblCxkdI/dmLAfMilvKX8IhbysL3Ct6mw3N29CUp7PwHqEQXh+j70YF+m5jUIv6HmWEh7t
UI7FsU1eJmuq5j5P8zSQLKKg7ySm9Jq5IWCSW2TlI3ZhlK/ks759SxYyyyJ+QVKCYaPVZ6Fhm
Lf8pJIuYnPll4UKX217rPcR8rMay8rqvdmocuBQ8mXIVicVWbRk+0llgusXQLhYbzwv2N1dB6
o0SJnBvxx2RxgcIxiPevAEm3JErnPEDrpYGalH5QNANX8=
X-Spam-Score: 2.9 (++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
has NOT identified this incoming email as spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
the administrator of that system for details.
Content preview: > There is a remaining problem, and I can't find a way to
fix it. > When a buffer already appeared in the window before, > then switching
to that buffer with e.g. 'C-x b' > moves it to the end of the [...]
Content analysis details: (2.9 points, 10.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
-0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at https://www.dnswl.org/,
low trust [212.227.17.22 listed in list.dnswl.org]
-0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2)
[212.227.17.22 listed in wl.mailspike.net]
3.6 RCVD_IN_SBL_CSS RBL: Received via a relay in Spamhaus SBL-CSS
[213.142.96.219 listed in zen.spamhaus.org]
-0.0 SPF_PASS SPF: sender matches SPF record
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail
provider (rudalics[at]gmx.at)
0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record
X-Debbugs-Envelope-To: 69993
Cc: 69993 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 1.9 (+)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
has NOT identified this incoming email as spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
the administrator of that system for details.
Content preview: > There is a remaining problem, and I can't find a way to
fix it. > When a buffer already appeared in the window before, > then switching
to that buffer with e.g. 'C-x b' > moves it to the end of the [...]
Content analysis details: (1.9 points, 10.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
-0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at https://www.dnswl.org/,
low trust
[212.227.17.22 listed in list.dnswl.org]
3.6 RCVD_IN_SBL_CSS RBL: Received via a relay in Spamhaus SBL-CSS
[213.142.96.219 listed in zen.spamhaus.org]
-0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2)
[212.227.17.22 listed in wl.mailspike.net]
-0.0 SPF_PASS SPF: sender matches SPF record
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail
provider (rudalics[at]gmx.at)
0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record
-1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list
manager
> There is a remaining problem, and I can't find a way to fix it.
> When a buffer already appeared in the window before,
> then switching to that buffer with e.g. 'C-x b'
> moves it to the end of the list. Technically
> this means that window-next-buffers is set to nil.
I'm not sure I understand. IIRC 'window-next-buffers' always returns
nil unless you invoked 'switch-to-prev-buffer' before. It serves to
"navigate" a window's buffer list, in particular, to "undo" preceding
'previous-buffer' calls when overshooting. 'switch-to-buffer' is not
part of such a scenario.
> However, I can't find code that does this. Could you help
> to find it? I already found one occurrence of
> (set-window-next-buffers window nil) in record-window-buffer.
> But after adding a condition with switch-to-prev-buffer-wrap
> it still moves the switched buffer to the end.
If you get me the patch you currently use and a scenario, I'll try.
martin
bug-gnu-emacs@HIDDEN:bug#69993; Package emacs.
Full text available.Received: (at 69993) by debbugs.gnu.org; 25 Mar 2024 17:21:06 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Mar 25 13:21:06 2024 Received: from localhost ([127.0.0.1]:36123 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1roo0Q-0006G2-64 for submit <at> debbugs.gnu.org; Mon, 25 Mar 2024 13:21:06 -0400 Received: from relay1-d.mail.gandi.net ([2001:4b98:dc4:8::221]:53119) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <juri@HIDDEN>) id 1roo0M-0006Ea-VP for 69993 <at> debbugs.gnu.org; Mon, 25 Mar 2024 13:21:03 -0400 Received: by mail.gandi.net (Postfix) with ESMTPSA id CF0CE24000C; Mon, 25 Mar 2024 17:20:56 +0000 (UTC) From: Juri Linkov <juri@HIDDEN> To: martin rudalics <rudalics@HIDDEN> Subject: Re: bug#69993: Wrap window buffers while cycling In-Reply-To: <3419df35-1b96-4a64-8ed7-722a05c58742@HIDDEN> (martin rudalics's message of "Mon, 25 Mar 2024 10:41:58 +0100") Organization: LINKOV.NET References: <86h6gug41x.fsf@HIDDEN> <3419df35-1b96-4a64-8ed7-722a05c58742@HIDDEN> Date: Mon, 25 Mar 2024 19:16:04 +0200 Message-ID: <86le66ckhj.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/30.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-GND-Sasl: juri@HIDDEN X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 69993 Cc: 69993 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.7 (-) >> So here is the patch that finally solves this problem >> by adding a new option 'switch-to-prev-buffer-wrap' >> disabled by default. > > Good idea. You probably should emphasize the point that if this option > is non-nil, the buffer switched to must have appeared in the window > before. Thanks for the suggestion, will add to the documentation. There is a remaining problem, and I can't find a way to fix it. When a buffer already appeared in the window before, then switching to that buffer with e.g. 'C-x b' moves it to the end of the list. Technically this means that window-next-buffers is set to nil. However, I can't find code that does this. Could you help to find it? I already found one occurrence of (set-window-next-buffers window nil) in record-window-buffer. But after adding a condition with switch-to-prev-buffer-wrap it still moves the switched buffer to the end.
bug-gnu-emacs@HIDDEN:bug#69993; Package emacs.
Full text available.
Received: (at 69993) by debbugs.gnu.org; 25 Mar 2024 16:01:44 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Mar 25 12:01:44 2024
Received: from localhost ([127.0.0.1]:35815 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1romlb-0006ei-Nx
for submit <at> debbugs.gnu.org; Mon, 25 Mar 2024 12:01:44 -0400
Received: from mout.gmx.net ([212.227.17.21]:35723)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <rudalics@HIDDEN>) id 1romlZ-0006eV-8H
for 69993 <at> debbugs.gnu.org; Mon, 25 Mar 2024 12:01:42 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.at;
s=s31663417; t=1711382496; x=1711987296; i=rudalics@HIDDEN;
bh=qRqkrtz3ASH3UAshJUahVlHsKZQUww8/3/KOzj3AKwA=;
h=X-UI-Sender-Class:Date:Subject:To:References:From:In-Reply-To;
b=JIt4JYRy2GPiOtgMvbi0ItVCd+WHeBcwbTLxSwAHFvQKdvNYeVcOuxwY5GiKxFB8
ll/QsJKjAvV98m+zF5TQvIs4CYMLphEsbV0Bu3974Mssd4mT6h4h4HpsuNKBv81CQ
Sj6wm23x6Nj1A9lf8G58sToeApEFZGV0Tp4i76rE5fch35xhZjeuI4DSX3MdJeagg
bxXBDa9an6X5nB7DloyDVlZ4qYSl6KNLqFZW/dqqtg40ajM5rbXVhYm/UIbC82PM0
1RUFbLZMNkEFU0TDYKc52v4Vr6Lv80hyKip5f2Zdt8N1OIJKmiIc6/TAHAcKPQK7f
sccCazPZk8y2iV1crg==
X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a
Received: from [192.168.31.113] ([212.95.5.240]) by mail.gmx.net (mrgmx104
[212.227.17.168]) with ESMTPSA (Nemesis) id 1MKbg4-1s9WXq3NbI-00KzP1; Mon, 25
Mar 2024 10:41:58 +0100
Message-ID: <3419df35-1b96-4a64-8ed7-722a05c58742@HIDDEN>
Date: Mon, 25 Mar 2024 10:41:58 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: bug#69993: Wrap window buffers while cycling
To: Juri Linkov <juri@HIDDEN>, 69993 <at> debbugs.gnu.org
References: <86h6gug41x.fsf@HIDDEN>
Content-Language: en-US
From: martin rudalics <rudalics@HIDDEN>
In-Reply-To: <86h6gug41x.fsf@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K1:mgxekKISTMCczquJ2fAV+z2i2iJKKumOH+H0nYi3M8k8Xen31DV
PWEbCYpzGnE1Ltt9awskWwSriGTf52SndLyXEwKrZ0zJhy25XsueCIEzf67svrl0yHW5pgq
dHDrxl51QZCuYpp1YS/Y8lJ0QvZHL3gDk3JegSN6VM6u3ZEQCWEZv+BtmaAWvLrzet5rZvP
vpVgYdvrJS+nQiCyf6FYg==
X-Spam-Flag: NO
UI-OutboundReport: notjunk:1;M01:P0:HkzoI0X0FDU=;zTxseqHoWAs2E4jIAOSu4DG9o1v
G+TMQUzgoz8nOrJCW7FEFE/wkHyY7kUsBXLxQzOyfTNE7G1QB/lKNxNZfpoUmv+hV8u29n4YI
W2zw4dPHZ4+JWZTpZsGnjs1dHngUMf50gKMXcjw72M87fd3wGsNgAv4kcqOSLJLwqXCYCvKQX
XvkBYs181lwGiJzZXg66xgHP9FvlHgGBGZ9eoLJBcEJI1PnyqvgJCg+3e+dymulNo9HlWaHzo
EzearWUJPdn1GSHXSgA6ZZFE2asLCshNNpaktGljXlivaQbhfk/6hUgz9+jWoqUSRqetyvUo4
xE+kAYWDqPYRJFdZhmP1uGSLdFrt7lWtywOPIzBC/T5hocXRrgGRyMR0CAlgTRRLjxm9P1lQ9
rsIFMLisRXC2EXvBaXyLH7JKRUpbUejd8idjwhYWkKJwKRQxwA9dWrfTXcnJukz/tRzHEAoOV
Krx00jGgB6WmDabyODvVEgJTX2dbHHfHKZ8+XEompB3f/VprWHPxMJDjmIw4dXPEJnmjBqJZO
05V/JfLC7KMWycFn14Nnw8UiDD3khzyLLxwqnA7RnAAQSdchkVGScOakgaeOzoAYFOCG7rw90
t7nPOYi5LE4K3g4TN+neiDz/npKX9X3Bkwc4kULe8j9vH8MK30F8s4hI1gcUUx8hrJP0kom3Y
4AgyMV7jmK+s9/YbOoHvJC1IHagVQKcllyzAlV7Qni1gJjYosSrQSUBpMY6F6BTjbfr2eYp0X
N51LSeDX4JVOE7DGaBL33XxdxdqrM4m3urwxDLCOS6mUn+q7DuHtMfTOICnLLOwGvii2oZdPg
yDC73svbcqHaMxugC1tuIX9iVTCkwU1qsE3uoos2Gbo4tyYW6NF9zOjzAuSehiJ/20
X-Spam-Score: 3.9 (+++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
has NOT identified this incoming email as spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
the administrator of that system for details.
Content preview: > Often users complain there is no way to wrap window buffers
> while cycling them with 'C-x C-<left>' (previous-buffer) > and 'C-x
C-<right>'
(next-buffer). One of the latest examples is > https://o [...]
Content analysis details: (3.9 points, 10.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
3.6 RCVD_IN_SBL_CSS RBL: Received via a relay in Spamhaus SBL-CSS
[212.95.5.240 listed in zen.spamhaus.org]
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail
provider (rudalics[at]gmx.at)
0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record
1.1 DATE_IN_PAST_06_12 Date: is 6 to 12 hours before Received: date
-0.0 SPF_PASS SPF: sender matches SPF record
-0.0 RCVD_IN_MSPIKE_H3 RBL: Good reputation (+3)
[212.227.17.21 listed in wl.mailspike.net]
-0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at https://www.dnswl.org/,
low trust [212.227.17.21 listed in list.dnswl.org]
-0.0 RCVD_IN_MSPIKE_WL Mailspike good senders
X-Debbugs-Envelope-To: 69993
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 2.9 (++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
has NOT identified this incoming email as spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
the administrator of that system for details.
Content preview: > Often users complain there is no way to wrap window buffers
> while cycling them with 'C-x C-<left>' (previous-buffer) > and 'C-x C-<right>'
(next-buffer). One of the latest examples is > https://o [...]
Content analysis details: (2.9 points, 10.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
3.6 RCVD_IN_SBL_CSS RBL: Received via a relay in Spamhaus SBL-CSS
[212.95.5.240 listed in zen.spamhaus.org]
-0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at https://www.dnswl.org/,
low trust
[212.227.17.21 listed in list.dnswl.org]
-0.0 RCVD_IN_MSPIKE_H3 RBL: Good reputation (+3)
[212.227.17.21 listed in wl.mailspike.net]
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail
provider (rudalics[at]gmx.at)
0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record
1.1 DATE_IN_PAST_06_12 Date: is 6 to 12 hours before Received: date
-0.0 SPF_PASS SPF: sender matches SPF record
-0.0 RCVD_IN_MSPIKE_WL Mailspike good senders
-1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list
manager
> Often users complain there is no way to wrap window buffers
> while cycling them with 'C-x C-<left>' (previous-buffer)
> and 'C-x C-<right>' (next-buffer). One of the latest examples is
> https://old.reddit.com/r/emacs/comments/1barvo2/perwindow_buffer_ordering/
>
> This problem becomes apparent when a list of prev/next window buffers
> is visualized by the tab-line.
>
> So here is the patch that finally solves this problem
> by adding a new option 'switch-to-prev-buffer-wrap'
> disabled by default.
>
> When its value is t, it wraps to the first/last buffer.
> But when the value is 'stop', it stops at the first/last buffer.
Good idea. You probably should emphasize the point that if this option
is non-nil, the buffer switched to must have appeared in the window
before.
martin
bug-gnu-emacs@HIDDEN:bug#69993; Package emacs.
Full text available.
Received: (at submit) by debbugs.gnu.org; 25 Mar 2024 07:49:03 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Mar 25 03:49:02 2024
Received: from localhost ([127.0.0.1]:47846 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1rof4n-00029O-Pp
for submit <at> debbugs.gnu.org; Mon, 25 Mar 2024 03:49:02 -0400
Received: from lists.gnu.org ([209.51.188.17]:41826)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <juri@HIDDEN>) id 1rof4j-00028n-Dk
for submit <at> debbugs.gnu.org; Mon, 25 Mar 2024 03:49:01 -0400
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 <juri@HIDDEN>) id 1rof42-0005Vm-Rn
for bug-gnu-emacs@HIDDEN; Mon, 25 Mar 2024 03:48:14 -0400
Received: from relay3-d.mail.gandi.net ([217.70.183.195])
by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from <juri@HIDDEN>) id 1rof3z-0004ak-Jb
for bug-gnu-emacs@HIDDEN; Mon, 25 Mar 2024 03:48:13 -0400
Received: by mail.gandi.net (Postfix) with ESMTPSA id 4AF9060005
for <bug-gnu-emacs@HIDDEN>; Mon, 25 Mar 2024 07:48:07 +0000 (UTC)
From: Juri Linkov <juri@HIDDEN>
To: bug-gnu-emacs@HIDDEN
Subject: Wrap window buffers while cycling
Organization: LINKOV.NET
X-Debbugs-Cc: martin rudalics <rudalics@HIDDEN>
Date: Mon, 25 Mar 2024 09:42:10 +0200
Message-ID: <86h6gug41x.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/30.0.50 (x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
X-GND-Sasl: juri@HIDDEN
Received-SPF: pass client-ip=217.70.183.195; envelope-from=juri@HIDDEN;
helo=relay3-d.mail.gandi.net
X-Spam_score_int: -25
X-Spam_score: -2.6
X-Spam_bar: --
X-Spam_report: (-2.6 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7,
RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001,
SPF_PASS=-0.001 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-Spam-Score: -1.7 (-)
X-Debbugs-Envelope-To: submit
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.7 (--)
--=-=-=
Content-Type: text/plain
Often users complain there is no way to wrap window buffers
while cycling them with 'C-x C-<left>' (previous-buffer)
and 'C-x C-<right>' (next-buffer). One of the latest examples is
https://old.reddit.com/r/emacs/comments/1barvo2/perwindow_buffer_ordering/
This problem becomes apparent when a list of prev/next window buffers
is visualized by the tab-line.
So here is the patch that finally solves this problem
by adding a new option 'switch-to-prev-buffer-wrap'
disabled by default.
When its value is t, it wraps to the first/last buffer.
But when the value is 'stop', it stops at the first/last buffer.
--=-=-=
Content-Type: text/x-diff
Content-Disposition: inline; filename=switch-to-prev-buffer-wrap.patch
diff --git a/lisp/window.el b/lisp/window.el
index df55a7ca673..4d727fb827c 100644
--- a/lisp/window.el
+++ b/lisp/window.el
@@ -4542,6 +4542,16 @@ set-window-buffer-start-and-point
(when point
(set-window-point window point))))
+(defcustom switch-to-prev-buffer-wrap nil
+ "Wrap to the first/last window-local buffer while cycling.
+When t, wrap to the first/last buffer.
+When the value is `stop', stop at the first/last buffer."
+ :type '(choice (const :tag "Never wrap" nil)
+ (const :tag "Stop at window-local buffers" stop)
+ (const :tag "Wrap to window-local buffers" t))
+ :version "30.1"
+ :group 'windows)
+
(defcustom switch-to-visible-buffer t
"If non-nil, allow switching to an already visible buffer.
If this variable is non-nil, `switch-to-prev-buffer' and
@@ -4676,7 +4686,7 @@ switch-to-prev-buffer
((or switch-to-prev-buffer-skip
(not switch-to-visible-buffer))
frame)))
- entry new-buffer killed-buffers skipped)
+ entry new-buffer killed-buffers skipped wrapped)
(when (window-minibuffer-p window)
;; Don't switch in minibuffer window.
(unless (setq window (minibuffer-selected-window))
@@ -4711,7 +4721,7 @@ switch-to-prev-buffer
;; buffer list in order to make sure that switching to the
;; previous/next buffer traverse it in opposite directions. Skip
;; this step for side windows.
- (unless window-side
+ (unless (or window-side switch-to-prev-buffer-wrap)
(dolist (buffer (if bury-or-kill
(buffer-list frame)
(nreverse (buffer-list frame))))
@@ -4729,7 +4739,9 @@ switch-to-prev-buffer
(set-window-buffer-start-and-point window new-buffer)
(throw 'found t)))))
- (unless bury-or-kill
+ (when (eq switch-to-prev-buffer-wrap 'stop)
+ (setq wrapped 'stop new-buffer nil))
+ (unless (or bury-or-kill (eq switch-to-prev-buffer-wrap 'stop))
;; Scan reverted next buffers last (must not use nreverse
;; here!).
(dolist (buffer (reverse next-buffers))
@@ -4744,6 +4756,7 @@ switch-to-prev-buffer
(if (switch-to-prev-buffer-skip-p skip window buffer bury-or-kill)
(setq skipped (or skipped buffer))
(setq new-buffer buffer)
+ (setq wrapped t)
(set-window-buffer-start-and-point
window new-buffer (nth 1 entry) (nth 2 entry))
(throw 'found t)))))
@@ -4770,8 +4783,23 @@ switch-to-prev-buffer
window (append (window-prev-buffers window) (list entry)))))
;; Move `old-buffer' to head of WINDOW's restored list of next
;; buffers.
- (set-window-next-buffers
- window (cons old-buffer (delq old-buffer next-buffers))))
+ (if (not (and switch-to-prev-buffer-wrap wrapped))
+ (set-window-next-buffers
+ window (cons old-buffer (delq old-buffer next-buffers)))
+ ;; Restore the right order of previous buffers.
+ (unless (eq wrapped 'stop)
+ (let ((prev-buffers (window-prev-buffers window)))
+ ;; Use the same sorting order as was in next-buffers
+ ;; with old-buffer at the bottom.
+ (setq prev-buffers
+ (sort prev-buffers
+ (lambda (a b)
+ (cond
+ ((eq (car a) old-buffer) nil)
+ ((eq (car b) old-buffer) t)
+ (t (< (length (memq (car a) next-buffers))
+ (length (memq (car b) next-buffers))))))))
+ (set-window-prev-buffers window prev-buffers)))))
;; Remove killed buffers from WINDOW's previous and next buffers.
(when killed-buffers
@@ -4812,7 +4840,7 @@ switch-to-next-buffer
((or switch-to-prev-buffer-skip
(not switch-to-visible-buffer))
frame)))
- new-buffer entry killed-buffers skipped)
+ new-buffer entry killed-buffers skipped wrapped)
(when (window-minibuffer-p window)
;; Don't switch in minibuffer window.
(unless (setq window (minibuffer-selected-window))
@@ -4839,7 +4867,7 @@ switch-to-next-buffer
(throw 'found t))))
;; Scan the buffer list of WINDOW's frame next, skipping previous
;; buffers entries. Skip this step for side windows.
- (unless window-side
+ (unless (or window-side switch-to-prev-buffer-wrap)
(dolist (buffer (buffer-list frame))
(when (and (buffer-live-p buffer)
(not (eq buffer old-buffer))
@@ -4856,19 +4884,22 @@ switch-to-next-buffer
(throw 'found t)))))
;; Scan WINDOW's reverted previous buffers last (must not use
;; nreverse here!)
- (dolist (entry (reverse (window-prev-buffers window)))
- (when (and (not (eq new-buffer (car entry)))
- (not (eq old-buffer (car entry)))
- (setq new-buffer (car entry))
- (or (buffer-live-p new-buffer)
- (not (setq killed-buffers
- (cons new-buffer killed-buffers))))
- (or (null pred) (funcall pred new-buffer)))
- (if (switch-to-prev-buffer-skip-p skip window new-buffer)
- (setq skipped (or skipped new-buffer))
- (set-window-buffer-start-and-point
- window new-buffer (nth 1 entry) (nth 2 entry))
- (throw 'found t))))
+ (if (eq switch-to-prev-buffer-wrap 'stop)
+ (setq wrapped 'stop new-buffer nil)
+ (dolist (entry (reverse (window-prev-buffers window)))
+ (when (and (not (eq new-buffer (car entry)))
+ (not (eq old-buffer (car entry)))
+ (setq new-buffer (car entry))
+ (or (buffer-live-p new-buffer)
+ (not (setq killed-buffers
+ (cons new-buffer killed-buffers))))
+ (or (null pred) (funcall pred new-buffer)))
+ (if (switch-to-prev-buffer-skip-p skip window new-buffer)
+ (setq skipped (or skipped new-buffer))
+ (setq wrapped t)
+ (set-window-buffer-start-and-point
+ window new-buffer (nth 1 entry) (nth 2 entry))
+ (throw 'found t)))))
(when (and skipped (not (functionp switch-to-prev-buffer-skip)))
;; Show first skipped buffer, unless skip was a function.
@@ -4876,7 +4907,13 @@ switch-to-next-buffer
(set-window-buffer-start-and-point window new-buffer)))
;; Remove `new-buffer' from and restore WINDOW's next buffers.
- (set-window-next-buffers window (delq new-buffer next-buffers))
+ (if (not (and switch-to-prev-buffer-wrap wrapped))
+ (set-window-next-buffers window (delq new-buffer next-buffers))
+ (unless (eq wrapped 'stop)
+ (let ((prev-buffers (window-prev-buffers window)))
+ (setq prev-buffers
+ (nreverse (delq new-buffer (mapcar #'car prev-buffers))))
+ (set-window-next-buffers window prev-buffers))))
;; Remove killed buffers from WINDOW's previous and next buffers.
(when killed-buffers
--=-=-=--
Juri Linkov <juri@HIDDEN>:rudalics@HIDDEN, bug-gnu-emacs@HIDDEN.
Full text available.rudalics@HIDDEN, bug-gnu-emacs@HIDDEN:bug#69993; Package emacs.
Full text available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.