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: Sat, 27 Apr 2019 10:30:43 +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> <83y33xvwgo.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="69817"; 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 Sat Apr 27 10:39:04 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 1hKIrN-000HvL-Fw for geb-bug-gnu-emacs@m.gmane.org; Sat, 27 Apr 2019 10:39:01 +0200 Original-Received: from localhost ([127.0.0.1]:57295 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hKIrM-0004SY-HO for geb-bug-gnu-emacs@m.gmane.org; Sat, 27 Apr 2019 04:39:00 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:45756) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hKIqS-0003aa-J1 for bug-gnu-emacs@gnu.org; Sat, 27 Apr 2019 04:38:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hKIje-0005Po-Hv for bug-gnu-emacs@gnu.org; Sat, 27 Apr 2019 04:31:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:48945) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hKIje-0005Pi-Eg for bug-gnu-emacs@gnu.org; Sat, 27 Apr 2019 04:31:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hKIje-0007sI-6M for bug-gnu-emacs@gnu.org; Sat, 27 Apr 2019 04:31: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: Sat, 27 Apr 2019 08:31: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.155635385930261 (code B ref 34765); Sat, 27 Apr 2019 08:31:02 +0000 Original-Received: (at 34765) by debbugs.gnu.org; 27 Apr 2019 08:30:59 +0000 Original-Received: from localhost ([127.0.0.1]:34256 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hKIja-0007s0-Ir for submit@debbugs.gnu.org; Sat, 27 Apr 2019 04:30:58 -0400 Original-Received: from mout.gmx.net ([212.227.15.19]:39061) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hKIjY-0007rm-SY for 34765@debbugs.gnu.org; Sat, 27 Apr 2019 04:30:57 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1556353844; bh=siEujE87TkvhrVkuAAktaj3wp/UFWJK4nvd2PcJf3hU=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=SvntCEE0t1dXL5QH7WBBmNb47Os5JR2oauYOaSg21yke8ZMY/uUASCMR1voQUC46G PItv9UziEY1aCOlauJOhZt0BgCQNDfTVjfMKGC+FvJQLNSvy/HDRg3OB8/ThW9dPdB X6P4FMR5RXUpcLQ+vpOvKXShVcSZtNW2w1/3jJqM= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Original-Received: from [192.168.1.101] ([212.95.5.70]) by mail.gmx.com (mrgmx001 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MfmWy-1h63f61sxw-00N8om; Sat, 27 Apr 2019 10:30:44 +0200 In-Reply-To: <83y33xvwgo.fsf@gnu.org> Content-Language: de-DE X-Provags-ID: V03:K1:edxr+r83PP6mWOHSHK1uO1qDv4mtXkrPUL4voxVbioALNfnzTKC 71GmSUAMJkTW+Sg6vATK411Alvd3bujkhlC0ew2jKpF2EuJwht/So+C7hbnSBRWzPH40DSQ 9RHEX884ndht9O5UcjsVpxEX4TlEQOb1/5vF0OnTx/hxiQhtQz9cH6gsaboWsVHmBXE93mL 3OCWjk4PExNwCK5asWjKA== X-UI-Out-Filterresults: notjunk:1;V03:K0:q8RJZ39l5is=:FPVw2a0dApPk1R8jke5pxZ GZaPtdY/QQfvuam3vg0qRENc+owyvl2ix5cYQGG1003jLjPz+EDWqTLQLhLT0AcZqf+vkGw8Z nhmH6EAZYzJY7Kc2jWWMWMeYr9y2/pFAikrGbdrIASY/WIwhqovDvCXs1p3ui+FRASscmG4Jg JGi3bMphHSw6A8L4ysbrJXlVkSGd9eWcCtDQvuF5jdNTV5T8jWHjD+0lqRzUzpxkZUs6Yhx/s fi7g8FY+UfX1UZ2Xc99BOVZatjHfof7Kt0TzY39Q6e+gpg3g0uArSw1uu31ToDl2Q3A+3oXaF OVc63nMe7ruyfBlrYj+dqETmro1aRXS7+ihK4P+vKhkXZXsbZPUSF/Fe+Gwl0DiJHcTORkvI7 CQfpVATZ7YU8l20JYPFGYWqj5+e71p7Je6Njsk6J0pWMoQaxBildtxcJpZhoTCw7yJauwHKMI FANt1+VgeIEphf+IVCT6osq0i3HNEUA2eCLJRMDDT85GMzgxKjqigsMR7GQmXXVRL3ujuYQM4 4ewFd5+kE4eXtECWR9hrIkZ5w3GHvKBi2GY3POuCq3lh3jxXQnlA3ctxLbww/G6PgTze5luoq Wxvb9De6luqg0zVtUs/zC+HiAz1UzJEEddNLv2twAu5g8Pt64ofbUVSB9kUGlyUDia1SvMOVJ rBMPFOGGTVcBhiAN3fWY52AiaAWmrgGa9itdig59OavQycGjQ3NjpSUoaqNPsLzaZM1/goP1D mpOo1oj+ZMD/AwNznP9dsqM5CirwYVXZV+OGiCGJyB+be6iddQS76sgkkimonRWVrrn8FYhG 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:158331 Archived-At: > Can we please use our style in commentary? We don't use bock comments > in Emacs, so I'd like not to proliferate them. Actually it's not a comment but a doc-string and if you customize 'font-lock-doc-face' you will notice. These were part of a project of mine to improve handling and readability of Emacs primitives' doc-strings (including font locking, Lisp syntax with completion and eldoc support, correct filling, exporting/importing from C to Lisp to texinfo and the like). But since I never managed to write some of these components, the project has stalled. I'll stop proliferating that style now. >> + if (!inhibit_buffer_hooks) >> + /* Run buffer-list-update-hook. */ >> + run_buffer_list_update_hook (buffer); > > It is somewhat strange that part of the reasons for not running hooks > are tested inside run_buffer_list_update_hook, and others explicitly > here. Any special reasons for this inconsistency? See below. >> +DEFUN ("get-buffer-create", Fget_buffer_create, Sget_buffer_create, 1, 1, 0, >> + doc: /* Return the buffer specified by BUFFER-OR-NAME, creating a new one if needed. >> +If BUFFER-OR-NAME is a string and a live buffer with that name exists, >> +return that buffer. If no such buffer exists, create a new buffer with >> +that name and return it. If BUFFER-OR-NAME starts with a space, the new >> +buffer does not keep undo information. >> + >> +If BUFFER-OR-NAME is a buffer instead of a string, return it as given, >> +even if it is dead. The return value is never nil. */) >> + (Lisp_Object buffer_or_name) >> +{ >> + return get_buffer_create (buffer_or_name, false); >> +} > > Should this function also acquire an additional optional argument? If > not, why not? You mean 'get-buffer-create'? I had that in a first version. But since you earlier expressed concerns about people abusing the extra argument of 'generate-new-buffer' I thought 'get-buffer-create' would be even more critical in this regard. In either case I'll do what you (or others) consider best. >> +Optional second argument INHIBIT-BUFFER-HOOKS non-nil means to not run >> +any buffer hooks ('kill-buffer-hook', 'buffer-list-update-hook' or >> +'kill-buffer-query-functions') for this buffer. This argument should > > The hooks should be quoted `like this', right? We do want them to > become hyperlinks. Right. >> +be set only for internal buffers that are never presented to users or >> +passed on to other applications. */) >> + (Lisp_Object name, Lisp_Object inhibit_buffer_hooks) >> +{ >> + Lisp_Object buffer_name = Fgenerate_new_buffer_name (name, Qnil); >> + Lisp_Object buffer = get_buffer_create (buffer_name, >> + !NILP (inhibit_buffer_hooks)); >> + >> + if (!NILP (inhibit_buffer_hooks)) >> + { >> + struct buffer *b = XBUFFER (buffer); >> + >> + b->inhibit_buffer_hooks = true; >> + } > > Should this flag be set inside get_buffer_create? If we do that, it would also resolve the "inconsistency" you bemoan above. So the answer is probably yes. > Quoting again. [...] > And here. Right. At least I show signs of consistency when adopting silly style. Thanks, martin