From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.devel Subject: Re: Switch buffers without modifying the buffer list ordering? Date: Mon, 31 Jan 2022 09:42:10 +0100 Message-ID: <1c2b4184-0f2a-95a7-16bd-d17f4bf6af53@gmx.at> References: <874k5kncd8.fsf@gmail.com> 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="8340"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Daniel Mendler , =?UTF-8?Q?Omar_Antol=c3=adn_Camarena?= To: Augusto Stoffel , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Jan 31 09:49:44 2022 Return-path: Envelope-to: ged-emacs-devel@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 1nESNb-00021x-Rp for ged-emacs-devel@m.gmane-mx.org; Mon, 31 Jan 2022 09:49:43 +0100 Original-Received: from localhost ([::1]:36464 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nESNa-0000Dl-BS for ged-emacs-devel@m.gmane-mx.org; Mon, 31 Jan 2022 03:49:42 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:57744) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nESGi-00026Y-KE for emacs-devel@gnu.org; Mon, 31 Jan 2022 03:42:37 -0500 Original-Received: from mout.gmx.net ([212.227.17.20]:50889) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nESGg-0000bA-AB for emacs-devel@gnu.org; Mon, 31 Jan 2022 03:42:36 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1643618532; bh=FP/V41p4aUEGS7gpUjedbaemU+sk7GfXI8HbJt5bvyQ=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=bYZzp88qxoeUC/VUpjg1VTai8j/qQbmqqtSdUlTyLurm8XVrtPsquDZ/4YStrhQqY 8vF/U5KfhaSVIWsXPT8/B3I+TFIGlZWeKYSl95VvJLVxyhTIRmBhRsmlTY2B9pNOiC rlDeHsD6e2cH7Vd01abKA6QvIpNCj1rXev83pU+M= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Original-Received: from [192.168.1.102] ([46.125.249.12]) by mail.gmx.net (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1M4s51-1nCXO02wTf-001veZ; Mon, 31 Jan 2022 09:42:11 +0100 In-Reply-To: <874k5kncd8.fsf@gmail.com> Content-Language: en-US X-Provags-ID: V03:K1:MTicmVLSWmhqwkFLovC9PwabuTzEWn6+dGlMb5sXn6BiPH29r1R +Qp2KTzJMKCD1x78oJNBqKCITk/owufx4CX88qBV6sKBMffiMQuVD/R8YbBojn1DhLI2Jgn N8XIqrT2e4hgZVdV9u0BXMVqux+4hYGchKlSQsL5gzWhwJVTRt0iWjEkLvloiK3eZ/QDxph idMYqMrELpXDIT0HFhrYQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:0x+tOW/Ds/g=:5WcR3kEqlunuokFeRPUllj nAJZ9hhwzEVSfGqPgLvE6o59KuTCqsNEqsgMIU6XmqyiI1ml0oVdp2nwN2o2cPsjJnMeYTPDK tRkCo35wHX4lVvGhKT1GijTvhk92gwnmgVhNz/VMEHpixDDR3rDmZXK5FK6GV3+uW3SxX7J2B +UZk1nKJJNxaM1qhUkjzpDdDugPwpdQ+4VGw2I4cFiUVCdGYel7sshHCWakha5v2FnOnnVDuA Sd6NNGG9Fx/IAHl0jCvkKWq44x4H4JADYwqcT8pWmKl9s8R5ewM9T7RKZNPTx3UNWP11Ii6BJ tOZbxDU4DKbR/Gc46WGXuezTHdVPcMRoXBI9Z7cm6Bedg1Kjt6cWMj/Y2WsWa5W9rLDDvHAtK vEcJWoqd2mGMcaycc2LwWYl6w5yk7IHF7vanFDycuwgPC2cwyNYsekDLjVLLuuuNAQI59t8Kx FGiqrRdzyOTleG8mDB3j2JlJXxvG2odm2IKU0KCrWfWuM5YsbnE6TVYLQczNxvn0RwnHWn+0R 1W6NDVUnFTWzHIkL5JpjGp0ZavaGqowLE8hhyOkvfgx0/TGlYhtGKh4pQFdH6h/Y2OO7Dqrw9 QlavrG2kDDDujIDKkmdDqxK1PheVmWFLJA7iGBEW9UGaFc/TYc3SduBjuIEGRftSBy3B34Gfy oBMbu4ofiiuOQE/Nh27ecLhu1IBgmYZTT+P8PXLyjUJOk6ah5CyOtPzWo8DxFkAUV35ulrTJ2 B+VXXov8772ttQF9qPmnYC2WbCZYc1n1iRBVmx5e7mUrM5Men+oWBYfp9jPWzOCpRX2En1WT Received-SPF: pass client-ip=212.227.17.20; envelope-from=rudalics@gmx.at; helo=mout.gmx.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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:285657 Archived-At: > With the following code, I can verify that the NORECORD argument of > `switch-to-buffer' does what it promises: > > ``` > (progn > (switch-to-buffer "A") > (switch-to-buffer "B" 'norecord) > (car (buffer-list))) > ``` > > Namely, this makes buffer B current, but returns #. > > Now, here's a catch: if next I type `M-x (car (buffer-list))', ... M-: (car (buffer-list)) I suppose ... > I get > # instead of #. Why does that happen, and is there > a way to switch to buffer B and *really* not modify the buffer list > ordering? It's restoring the window configuration after reading from the minibuffer but before evaluating the expression you typed that gets in the way. Try with emacs -Q and evaluate the forms below step by step (display-buffer "*Messages*") (defun foo () (message "%s - %s" (selected-window) (car (buffer-list)))) (add-hook 'buffer-list-update-hook 'foo) (progn (switch-to-buffer "A") (switch-to-buffer "B" 'norecord) (car (buffer-list))) and now type M-: (car (buffer-list)). This gets me in the *Messages* buffer # - A [3 times] # # - A # - *Minibuf-1* [4 times] # - B [2 times] # Now try again the same scenario but first evaluate (setq read-minibuffer-restore-windows nil) which gets me here the # - A [3 times] # you probably expected. > I'm asking this because of an issue with the live preview feature of the > Consult package. Very succinctly, the idea here is to temporarily > change the current buffer during a `completing-read' call, in order to > display more information about the candidates. When the > `completing-read' ends, we would like to restore the original order of > the buffer list. There seems to be no simple way to achieve that, and > some kludge like the following seems necessary. Any better suggestions? > > ``` > (let ((buffers (buffer-list))) > (unwind-protect > > (save-window-excursion > ;; Restore the original buffer list ordering > (dolist (buffer buffers) > (when (buffer-live-p buffer) > (bury-buffer-internal buffer)))))) That's a different issue. 'buffer-list' is a function that returns a list from the internal C variable Vbuffer_alist - a variable, Lisp code is not allowed to modify directly. In order to modify Vbuffer_alist, a Lisp programmer has to bury buffers in precisely the same way as you do. You could try coming up with a macro, say 'with-buffer-list-unmodified' (where you probably should suspend calling 'buffer-list-update-hook' while running it). martin