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: Thu, 25 Apr 2019 12:31:20 +0200 Message-ID: <8cc9317a-848f-53cb-4664-1c6e63fe7e11@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> <91d6aceb-5615-5706-99b8-d7f649c5ad87@gmx.at> <83k1fj3bd0.fsf@gnu.org> <520f7a25-03ba-bab0-0826-1c03af207394@gmx.at> <83v9z2zcwe.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="159167"; 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 Thu Apr 25 12:32:14 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 1hJbfo-000fG2-4J for geb-bug-gnu-emacs@m.gmane.org; Thu, 25 Apr 2019 12:32:12 +0200 Original-Received: from localhost ([127.0.0.1]:55011 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hJbfn-0008LD-2t for geb-bug-gnu-emacs@m.gmane.org; Thu, 25 Apr 2019 06:32:11 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:51655) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hJbff-0008Kl-Ta for bug-gnu-emacs@gnu.org; Thu, 25 Apr 2019 06:32:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hJbfe-0003lz-HH for bug-gnu-emacs@gnu.org; Thu, 25 Apr 2019 06:32:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:44032) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hJbfe-0003ki-BT for bug-gnu-emacs@gnu.org; Thu, 25 Apr 2019 06:32:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hJbfd-0005D1-Qm for bug-gnu-emacs@gnu.org; Thu, 25 Apr 2019 06:32:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 25 Apr 2019 10:32:01 +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.155618829719989 (code B ref 34765); Thu, 25 Apr 2019 10:32:01 +0000 Original-Received: (at 34765) by debbugs.gnu.org; 25 Apr 2019 10:31:37 +0000 Original-Received: from localhost ([127.0.0.1]:57576 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hJbfE-0005CL-N1 for submit@debbugs.gnu.org; Thu, 25 Apr 2019 06:31:36 -0400 Original-Received: from mout.gmx.net ([212.227.17.20]:34417) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hJbfC-0005C8-Ep for 34765@debbugs.gnu.org; Thu, 25 Apr 2019 06:31:35 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1556188282; bh=77xLoVFv0Zd07r8lY9Ncqe7jl0Jf6wW8fnwz87vGA0k=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=BAY4XG4X9E7+Y/kCs0851ouBn6FSccpKAmIPc/ZEaJiehqQq6fyK6h5gkMmGl8JG6 mrnirJ0lhA/QfN34da4tzVHJK3suk6LUwD4+eW2lQefavP3Jfi8G3sEe92+3WMa//q koQvK9z09/e2wvonfo6S/dr6A4RWXqKPqhoRDX9s= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Original-Received: from [192.168.1.101] ([212.95.5.199]) by mail.gmx.com (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MtOKc-1gWa2e1TI6-00unBE; Thu, 25 Apr 2019 12:31:22 +0200 In-Reply-To: <83v9z2zcwe.fsf@gnu.org> Content-Language: de-DE X-Provags-ID: V03:K1:GmKp+mqEFAnZcUGAOEgEUYJJ4pifQoXytNZ3IaGV/4XAPE0MWc9 XNE2lRAD1dGOLx0tnvO/YxOEvlluMh7YyBjCk34EA5QabjFC6U1/EGLquXP5bGR1CZm+lOv WHvAPWvgJsPNaC6cIQ6uxyiW+bax5O8D35rk+OR20f7fMplZiCAZYF1Bkdn2SQy9NeRVkzt UmbIJrePK2yDZbnLo0Vxw== X-UI-Out-Filterresults: notjunk:1;V03:K0:iWcP8s2MB7g=:5VzsV0z/tWGp+ATWOng55Z nlEPunBcqzihuK45F8/k7MmOX+ziDoRV0m2L382iIluMs7TlWc4NKroybxF5Bo4LfV6OBbFj3 cxhKDavqO7Tx0HSXiIBwidxWWnEWIyCozQBa3QJ/R34Q4EjS9TcTPyewX0gvYilF1oewcfeXe E1le9r2MGQp6xmMenwgxmzQJsG4NgEyKCK7w1zG9zIZaU4330Qf4mxRwDzuVJ6hfum/hMMecP 1leDMDzS5tItRuDAz6DDCC6pzowuW9GlMoSG57wRopTmvQEmSznA+3CEoU+TRLVhgY3qGcOoZ BGcimzOYQyJ2vNn7gr4YoVUT3Frrs0hxQVdA3X14kOt9bV0c4D0fCl/80XySKdwIK8hYfBKWj 4QrHpyMtnf25oy7aF7Wmo3iMg4pePfkdBu1+IuDg8BkQkdmJwojciITVMZUWPq1ZJ8RQQsAIw xHZRAUXGqpus3MU2ExYaHebxz53ThnLahDWmRBnUOMT38O3k3e0OLL2cRm970tDwPvdJXVMdM rijr23sJje+kQ/ICJ1vXNgxnCUnRPqhNCUPKoSe1AHmNj65lRZMzjt9Dg6TcDLX4deHwSdUzH JzUXC3IH7yKP98rX/5i3x/RWhWMzMZhiSwkdwcPtb5kzkNLOaDzb3fVl+/6eHT/7M2V+dktTt nnwZQwEP0zx+RRVoHEEKGVcB8aBN79ZKYYil4oivmDY/kwB0jf+zqkadSPoohPLuVRSZlTlWi VixK9iVkvwESbigfpglA0WM/ivXO9L9rxsfMS4pUUMzLRmPJ8hdCvWXmW+iBZkrEuUqKUxGo 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:158242 Archived-At: >> > I meant to suggest that get-buffer-create sets this flag when the name >> > of the buffer fits the template of temporary buffers. Exactly like it >> > does for code-conversion buffers now. >> >> We don't have a "template of temporary buffers". > > Of course we do: with-temp-buffer produces buffer names that follow > such a template. IIUC we'd need an expression similar to Vcode_conversion_workbuf_name to use in 'get-buffer-create' b->inhibit_buffer_hooks = (STRINGP (Vcode_conversion_workbuf_name) && strncmp (SSDATA (name), SSDATA (Vcode_conversion_workbuf_name), SBYTES (Vcode_conversion_workbuf_name)) == 0); So we could specify, for example, staticpro (&Vtemp_buffer_name); Vtemp_buffer_name = build_pure_c_string (" *temp*"); and rewrite the above assignment as b->inhibit_buffer_hooks = ((STRINGP (Vcode_conversion_workbuf_name) && strncmp (SSDATA (name), SSDATA (Vcode_conversion_workbuf_name), SBYTES (Vcode_conversion_workbuf_name)) == 0) || (STRINGP (Vtemp_buffer_name) && strncmp (SSDATA (name), SSDATA (Vtemp_buffer_name), SBYTES (Vtemp_buffer_name)) == 0)); >> For example, a buffer specified by the BUFNAME arg of >> 'with-output-to-temp-buffer' should not match such a template. > > Such buffers should not necessarily be exempt from running the hooks, > AFAIU. In any case, one can always bind the hook locally to nil in > the body of the macro, right? Unless the body changes the buffer list in some signifcant way, for example, by creating or deleting another buffer. >> But I'd favor a solution that skips all buffers whose name starts >> with a space as we do for 'other-buffer' or 'unbury-buffer'. > > I think this is too drastic a measure. We should only disable the > hooks in buffers where no one in their right minds will ever want to > run them. Then what about the buffers created by 'with-temp-file' or 'with-output-to-string'? martin