From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Juri Linkov Newsgroups: gmane.emacs.bugs Subject: bug#69993: Wrap window buffers while cycling Date: Tue, 02 Apr 2024 09:37:36 +0300 Organization: LINKOV.NET Message-ID: <86v850jmmo.fsf@mail.linkov.net> References: <86h6gug41x.fsf@mail.linkov.net> <3419df35-1b96-4a64-8ed7-722a05c58742@gmx.at> <86le66ckhj.fsf@mail.linkov.net> <86h6gs2lk7.fsf@mail.linkov.net> <5c71ea64-0f97-4b90-af61-1156fe33f1ea@gmx.at> <86cyreu78w.fsf@mail.linkov.net> <463c9242-56ef-4c99-9fe6-4b70be2071b2@gmx.at> <86sf0abeg3.fsf@mail.linkov.net> <86v855ggkv.fsf@mail.linkov.net> <91327e7b-d0a5-4f3a-a1f8-218d118608d6@gmx.at> <86sf07bnl4.fsf@mail.linkov.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="40672"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/30.0.50 (x86_64-pc-linux-gnu) Cc: 69993@debbugs.gnu.org To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Apr 02 08:42:20 2024 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1rrXqe-000AS6-Ca for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 02 Apr 2024 08:42:20 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rrXqJ-0006rz-RS; Tue, 02 Apr 2024 02:41:59 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rrXqI-0006ro-SL for bug-gnu-emacs@gnu.org; Tue, 02 Apr 2024 02:41:58 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1rrXqI-0002qE-Kt for bug-gnu-emacs@gnu.org; Tue, 02 Apr 2024 02:41:58 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rrXqL-0008Cd-O8 for bug-gnu-emacs@gnu.org; Tue, 02 Apr 2024 02:42:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Juri Linkov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 02 Apr 2024 06:42:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 69993 X-GNU-PR-Package: emacs Original-Received: via spool by 69993-submit@debbugs.gnu.org id=B69993.171204007731394 (code B ref 69993); Tue, 02 Apr 2024 06:42:01 +0000 Original-Received: (at 69993) by debbugs.gnu.org; 2 Apr 2024 06:41:17 +0000 Original-Received: from localhost ([127.0.0.1]:52137 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rrXpc-0008A6-Be for submit@debbugs.gnu.org; Tue, 02 Apr 2024 02:41:17 -0400 Original-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 ) id 1rrXpX-00088W-Iu for 69993@debbugs.gnu.org; Tue, 02 Apr 2024 02:41:14 -0400 Original-Received: by mail.gandi.net (Postfix) with ESMTPSA id 81603FF806; Tue, 2 Apr 2024 06:41:00 +0000 (UTC) In-Reply-To: (martin rudalics's message of "Sun, 31 Mar 2024 10:32:30 +0200") X-GND-Sasl: juri@linkov.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:282499 Archived-At: > 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 ' and 'C-x ' 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.