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: Tue, 21 May 2019 12:04:46 +0200 Message-ID: References: <5C7FD591.9090505@gmx.at> <83lg1sc8ob.fsf@gnu.org> <5C8009F3.5000405@gmx.at> <767e1b59-6ac2-cd11-076e-82a56ac53e29@gmx.at> <11be4631-b087-52a3-92fe-4cbd5248908d@gmx.at> <838svxxk41.fsf@gnu.org> <49c11920-0909-dcc2-4a39-4cdcfaf20453@gmx.at> <87lfzwg04h.fsf@tcd.ie> <87ftp9jl8q.fsf@tcd.ie> <5f39dc18-e4d4-dfbc-3bed-18542a10aedb@gmx.at> <87v9y4p7c6.fsf@tcd.ie> 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="256750"; mail-complaints-to="usenet@blaine.gmane.org" Cc: 34765@debbugs.gnu.org, alexanderm@web.de, monnier@IRO.UMontreal.CA To: "Basil L. Contovounesios" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue May 21 12:16:27 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 1hT1oo-0014fo-UX for geb-bug-gnu-emacs@m.gmane.org; Tue, 21 May 2019 12:16:27 +0200 Original-Received: from localhost ([127.0.0.1]:50701 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hT1on-0002bQ-Lb for geb-bug-gnu-emacs@m.gmane.org; Tue, 21 May 2019 06:16:25 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:46246) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hT1dq-0000ca-K6 for bug-gnu-emacs@gnu.org; Tue, 21 May 2019 06:05:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hT1do-0004vg-Hu for bug-gnu-emacs@gnu.org; Tue, 21 May 2019 06:05:06 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:53407) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hT1dm-0004tn-SI for bug-gnu-emacs@gnu.org; Tue, 21 May 2019 06:05:04 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hT1dm-0008PJ-LB for bug-gnu-emacs@gnu.org; Tue, 21 May 2019 06:05: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: Tue, 21 May 2019 10:05: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.155843310132306 (code B ref 34765); Tue, 21 May 2019 10:05:02 +0000 Original-Received: (at 34765) by debbugs.gnu.org; 21 May 2019 10:05:01 +0000 Original-Received: from localhost ([127.0.0.1]:38718 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hT1dk-0008P0-T0 for submit@debbugs.gnu.org; Tue, 21 May 2019 06:05:01 -0400 Original-Received: from mout.gmx.net ([212.227.17.22]:41845) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hT1di-0008Oi-Dk for 34765@debbugs.gnu.org; Tue, 21 May 2019 06:04:58 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1558433087; bh=0IilPE0SmL2cZswkOcdpSsypiFw73Hg04DLZ2/XT8TI=; h=X-UI-Sender-Class:From:Subject:To:Cc:References:Date:In-Reply-To; b=WPUjCAyNUWKn2xDnw3x6virwNh0tOO9j+f6gCovewBbkyaX6qZi82P+Mg8u0KtRGU +1yMWGfGS31CgknoLRCMEwEYYPE4g7f8RzFcExiFdsSgEAFVVXRm0XPKBBqM8w5qfa Gl6On09g8V7bOeeMkw/w9FSQng3ya3n30skvkTto= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Original-Received: from [192.168.1.101] ([212.95.5.239]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MKYpv-1hTIU40AzP-0020cu; Tue, 21 May 2019 12:04:47 +0200 In-Reply-To: <87v9y4p7c6.fsf@tcd.ie> Content-Language: de-DE X-Provags-ID: V03:K1:I71FdhfhOZZARggtqGwcqpc24FgG0eov219TGAdEpjEW/ur3wmh i3FsnyPVbp41o9BGAnVRAWy2ooi9GJl881oSUTfe4FG+mWKWcwxtBe1JwSfx0PtAfWWJHwt cqHJB/hdTlqj4uxsw2t6BCCN2zjer0bLygJSp0t4sBGRa1xnfN7OgCi770yBq/MsKY7Cpwn w1LvQEC2W0DEMKC9ZXOnA== X-UI-Out-Filterresults: notjunk:1;V03:K0:Rnsw9WOrJhk=:+jFGT/S8xCtLLdUz8fFhmn zOllcrAOxz1PU74rRO2vnJy4KIkMh3kT4KEZhWfsVtizRM9+2YIMfD2u+fow9+ix98214yLsU UrAOTuCOzVr7GATkHVedPak4V7aD60OvhA3qHXKQda5Iwz3uAoCL+AE9eLdgUxxQic1EFr4lU AK3cNjWkxVxUlox3eYs9LDJTQfS3TE8F2jwoN0++L62t2SYWJFucNUUT7u/CYkC2VhraM804K qis5/nVE0LhDYXFVOzftoluNVqHISmu9sceeirmovrkG/TP+UAscq0z3kstKKYeGsEohpgvTK kno2tTe6C6yjNRKLNfr548hAj2NPjld8aZGZoO+kpXfdro/XmNfzYtJ+lr1t8Fd0G4XcMODpk QtLxY35NfKtKwMlo5wTIljP9pFJ6GiXufILJXMX6Mu4NTV01xHqMazXgzwGuhhMTIm8smtbdJ T5Mx1W6VTrcCCZy/s70lZn6IUb/7mRvLvHjiIQPkY9gn+c7U3yCc5WEdy9xSMiNfxdvvFV3F7 5z7MEJisWQstKG9bH3Lduk0QbC4nm6odTJ6FMVB/8A7nR16PjW7PfbDEspgEM9eC/0+4mRPXm zpbsfAiPbPj80NkakeLZEaYv6R1iK0CfcoNqfIrH84KgSuOOKUbZkO4pNmNhK6XzO5/yjJzbm xiQllygTHh/jFhRw1MFxT2geI3DeVNfk5xhlL+olbkf9adVaGLDRbUh7ZuGmmqco4UhiK3Qnl th/KFyIuGPdSFSCJVq5XUBvgAjBLbtfROoElY8Qrgwu3uHj8y38e+yU+XqNzDsClAJMK+ULi 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:159607 Archived-At: >>>> It would be nice to get rid of the entire >>>> >>>> b->inhibit_buffer_hooks >>>> = (STRINGP (Vcode_conversion_workbuf_name) >>>> && strncmp (SSDATA (name), SSDATA (Vcode_conversion_workbuf_name), >>>> SBYTES (Vcode_conversion_workbuf_name)) == 0); >>>> >>>> form in 'get-buffer-create'. Any ideas? >>> >>> Doesn't your patch in https://debbugs.gnu.org/34765#86 already eliminate >>> the need for it? >> >> FWIW no, it leaves that form in place. > > I know, my emphasis was on eliminating the *need* for it. That's what I meant with the above. In code_conversion_save we should get rid of _both_ Fget_buffer_create instances but but I have not managed to understand the Vcode_conversion_workbuf_name vs Vcode_conversion_reused_workbuf rigmarole yet. > The possibilities for the buffer creation subroutine are either to act > specially on certain buffer name prefixes, or to accept an extra > argument indicating what to do, no? Are there any others? There was > mention of exposing a buffer-local variable to Elisp, but IIRC setting > that after creating the buffer would already be too late. So far there is no extra argument, the entire analysis is based on examining the proposed name argument. > Buffer names starting with spaces are already special in some contexts, > so extending that idea for inhibiting buffer hooks doesn't sound too > bad, Eli thinks that "this is too drastic a measure". > but the extra flag seems equally elegant and more > backward-compatible. Am I missing something? The piece we are discussing here namely how to get rid of the stuff at the top of this mail. And issues Eli raised earlier - whether 'get-buffer-create' should accept an extra argument or whether it should set b->inhibit_buffer_hooks = true. martin