From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: martin rudalics via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#69993: Wrap window buffers while cycling Date: Wed, 27 Mar 2024 09:48:38 +0100 Message-ID: <5c71ea64-0f97-4b90-af61-1156fe33f1ea@gmx.at> References: <86h6gug41x.fsf@mail.linkov.net> <3419df35-1b96-4a64-8ed7-722a05c58742@gmx.at> <86le66ckhj.fsf@mail.linkov.net> <86h6gs2lk7.fsf@mail.linkov.net> Reply-To: martin rudalics Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="20914"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla Thunderbird Cc: 69993@debbugs.gnu.org To: Juri Linkov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Mar 27 09:49:33 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 1rpOyT-0005BZ-Hc for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 27 Mar 2024 09:49:33 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rpOy0-0007tz-Qn; Wed, 27 Mar 2024 04:49:04 -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 1rpOxy-0007ta-P6 for bug-gnu-emacs@gnu.org; Wed, 27 Mar 2024 04:49:02 -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 1rpOxy-0003pF-Eg for bug-gnu-emacs@gnu.org; Wed, 27 Mar 2024 04:49:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rpOxy-000582-E7 for bug-gnu-emacs@gnu.org; Wed, 27 Mar 2024 04:49:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 27 Mar 2024 08:49:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 69993 X-GNU-PR-Package: emacs Original-Received: via spool by 69993-submit@debbugs.gnu.org id=B69993.171152933319627 (code B ref 69993); Wed, 27 Mar 2024 08:49:02 +0000 Original-Received: (at 69993) by debbugs.gnu.org; 27 Mar 2024 08:48:53 +0000 Original-Received: from localhost ([127.0.0.1]:35743 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rpOxn-000565-G7 for submit@debbugs.gnu.org; Wed, 27 Mar 2024 04:48:53 -0400 Original-Received: from mout.gmx.net ([212.227.17.22]:33899) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rpOxj-00052k-8K for 69993@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@gmx.at; 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 Original-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 Content-Language: en-US In-Reply-To: <86h6gs2lk7.fsf@mail.linkov.net> X-Provags-ID: V03:K1:GVnGB2IuUohF0BX38bmduwftTyFi3jBXDlFn5tZLtIQrDyI3mZS 32OABYiLnrIZD0UkPlBlTmSJOo5k/BIxUSfSMOl134jJtXaphAoeZs+FvDhOiauU7dCnCua sG13o4P5HDlmJhF8Y728OK5ncUunbRbSeNRLZARGP6uyoJu8zSWUM9nWETNiEJSOa2a4xwd XK/4ywGMIuR5zqgMzXLjQ== 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/jiMbjTRTfFMRPwKboao5ue5Slf6ExEi8QqvxOnCVhQ 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:282128 Archived-At: >> 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