From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.bugs Subject: bug#34765: 26.1; with-temp-buffer should not run buffer-list-update-hook Date: Wed, 24 Apr 2019 09:27:59 +0200 Message-ID: <91d6aceb-5615-5706-99b8-d7f649c5ad87@gmx.at> References: <5C7FD591.9090505@gmx.at> <83lg1sc8ob.fsf@gnu.org> <5C8009F3.5000405@gmx.at> <767e1b59-6ac2-cd11-076e-82a56ac53e29@gmx.at> <831s1t57q9.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="38869"; mail-complaints-to="usenet@blaine.gmane.org" Cc: 34765@debbugs.gnu.org, alexanderm@web.de, monnier@IRO.UMontreal.CA To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Apr 24 09:35:07 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hJCQt-0009yC-K3 for geb-bug-gnu-emacs@m.gmane.org; Wed, 24 Apr 2019 09:35:07 +0200 Original-Received: from localhost ([127.0.0.1]:37275 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hJCQs-00082H-IG for geb-bug-gnu-emacs@m.gmane.org; Wed, 24 Apr 2019 03:35:06 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:47780) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hJCNt-0005hs-JG for bug-gnu-emacs@gnu.org; Wed, 24 Apr 2019 03:32:02 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hJCL0-0003j2-Af for bug-gnu-emacs@gnu.org; Wed, 24 Apr 2019 03:29:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:41378) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hJCL0-0003ib-74 for bug-gnu-emacs@gnu.org; Wed, 24 Apr 2019 03:29:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hJCL0-0006Dc-2v for bug-gnu-emacs@gnu.org; Wed, 24 Apr 2019 03:29: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, 24 Apr 2019 07:29:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 34765 X-GNU-PR-Package: emacs Original-Received: via spool by 34765-submit@debbugs.gnu.org id=B34765.155609089423834 (code B ref 34765); Wed, 24 Apr 2019 07:29:02 +0000 Original-Received: (at 34765) by debbugs.gnu.org; 24 Apr 2019 07:28:14 +0000 Original-Received: from localhost ([127.0.0.1]:54919 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hJCKD-0006CL-Uj for submit@debbugs.gnu.org; Wed, 24 Apr 2019 03:28:14 -0400 Original-Received: from mout.gmx.net ([212.227.15.19]:50143) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hJCKC-0006C2-2c for 34765@debbugs.gnu.org; Wed, 24 Apr 2019 03:28:12 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1556090879; bh=XAxcpTg5Cc0KLd3g5AZDX+4rpK4FtscIsr708Tj3dGI=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=fQ1ekxXARL1chzTb8CTDlMcRrtv8DVtD3Nm1vsXBKxrTeY5Pxo166JvM1gJZlg9hI OBGtbpYTiEGAaAQ9hlo+V5FdU74ZKr1/vXKVF2HyR+hlASlyBjuOyLJPX1BKvff1hW uK7NGINwwM6rFZ60w1JIJB7b18jM1KNE5LJxW8kg= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Original-Received: from [192.168.1.101] ([212.95.5.219]) by mail.gmx.com (mrgmx002 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MX1hk-1hG0tf2s6u-00VxBY; Wed, 24 Apr 2019 09:27:59 +0200 In-Reply-To: <831s1t57q9.fsf@gnu.org> Content-Language: de-DE X-Provags-ID: V03:K1:eBCqxVXmB7LdWdFXrW1fhetqyeKOtIpACmDQ7fHHoQ0gb9bn+nu kEOFjTFK2ys9ef2rGYoFHctxeLtJdraJGkrW+TMb1hH5iDfMYyglCKnjDyNwLh5zrY9PX+r hceVRlGPJDHXKiY0OGiJgfHnkDpLarg08DFzzGdrE74qUYnjeHwy/qihLaShqvJw2jSPHxe XhcidPyVmVhg088ktDTsg== X-UI-Out-Filterresults: notjunk:1;V03:K0:pmX5zOVeTp4=:nZwL188a/WlPlJmAOGFHXd U9aXdwCxIoeYEDMu8P1wxnTPEOMUj+6ojgla0q9BC0X3ghLBpPKEiizmJvbO62711MbqduT5V 1DJN7QaKyzA5zjHxJFG947tlPOUsnBdc0UVk021ajwZIRBda+uKtIOChyXVny7wpyQE8tsjMR a9Qt4qtE9faPxZ/8RsPqTETB5AcRruKtlcFWJ6rAMOJC+HeBTffs95n4dKCUJUbP0u03227xW MBb4WK8vxGxde3z5Q5fS1qcCQ2Hr4P4kxR7VW7bEXsHZEiJ/qWsDNp2t7xUcMobuavPue/Ui2 Z8npymNE7qo1VnnbvUdgIu9e/fof3WRM/eRWE/DpjNIJHPMWOkZWyceoDWHkFD0ufzsJS+RAq MHCnjajFOsaPdhkIiaCVyUPJQsN9dRKUkKshIrryCm92ZlB4ckU3nPj/MID/Gs2SKo0MBdect g4WyBLd6C8kGEwxk6Ua2XMxV2vycuPg9Vl43v9RD5eg9fmKHtQfhnaWlX1wjEga50VhGqmD8Z 6bzKEDAbFPYqwpFHjZEd6NlTlqaCqyEU7UVZFgPpQWM2ngAay8BYlzZ7gBpbG3o+9Gxue01Ul EAsjIsLjM9nFSNb5wVjLbxTms8LaxRwykIBe/BKyVYRfdlo3iq09QB2N3ymp+UWdWl/OUZZC/ PqYXKRNS5gBX4rFPtVwWlyy573bErcv1/oLEfG6uuMxEpk9UJWPc8ELu5c4Y8OJpbBPj5Jh0M bQYzkHIw25tSVpLDO9rr+HoofjNd/iEVbECNDNzuc1FE45uNahV2AsdemIJ0fYOQw/w2vNgf X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 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.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:158170 Archived-At: >> Stefan asked me to add a variable 'inhibit-buffer-list-update-hook' >> and I came up with the attached. WDYT? > > Did he also ask you to remove the inhibit_buffer_hooks flag of the > buffer object? I'd rather prefer that you set that flag for temporary > buffers. In any case, removing the flag will get back the problem > with hidden buffers used by coding.c, right? I don't want to lose > that. FWIW handling of the the inhibit_buffer_hooks flag is unaffected by my patch. Note that I special cased the call from 'make-indirect-buffer' which is the only one that doesn't check that flag. > More generally, I don't understand the need for this variable. If we > just want to inhibit the hooks for temporary buffers, we don't need to > provide a variable, we can do that internally and unconditionally. > The variable assumes there are other legitimate use cases where a Lisp > program would want to inhibit the hooks, and that we agree to let Lisp > programs do that. What are those use cases? I don't know. The one we care about in the case at hand is that of 'with-temp-buffer' which seems innocuous enough for being used in the body of a function run by 'buffer-list-update-hook'. Since that macro is in subr.el and as such cannnot easily set the inhibit_buffer_hooks flag, the 'inhibit-buffer-list-update-hook' variable provides a simple workaround. But maybe Stefan himself can explain the rationale for such a variable. IIUC his main motivation was that by rebinding 'inhibit-buffer-list-update-hook' to nil one can from Lisp relax the restrictions provided by my patch. martin