GNU bug report logs - #49160
28.0.50; [PATCH] Uninitialized inhibit_buffer_hooks

Previous Next

Full log

Message #29 received at 49160 <at> debbugs.gnu.org (full text, mbox):

From: "Basil L. Contovounesios" <contovob <at> tcd.ie>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: larsi <at> gnus.org, 49160 <at> debbugs.gnu.org, dick.r.chiang <at> gmail.com
Subject: Re: bug#49160: 28.0.50; [PATCH] Uninitialized inhibit_buffer_hooks
Date: Wed, 11 Jan 2023 21:16:20 +0000

Eli Zaretskii [2023-01-11 15:22 -0500] wrote:

>> From: "Basil L. Contovounesios" <contovob <at> tcd.ie>
>> Cc: Eli Zaretskii <eliz <at> gnu.org>,  49160 <at> debbugs.gnu.org,  dick
>>  <dick.r.chiang <at> gmail.com>
>> Date: Wed, 11 Jan 2023 20:13:21 +0000
>> 
>> Fmake_indirect_buffer continues to run buffer-list-update-hook
>> regardless of the new argument.  Any objections to changing that?
>
> buffer-list-update-hook is not a buffer-hook, strictly speaking.

Right, but it's inhibited together with 'strict' buffer-hooks (and
documented as such) everywhere except for make-indirect-buffer: see
get-buffer-create, generate-new-buffer, struct buffer, "(elisp) Buffer
List", "(elisp) Creating Buffers", "(elisp) Buffer Internals", and
etc/NEWS.28.

In fact, "(elisp) Indirect Buffers" even says about
make-indirect-buffer:

     *Note Creating Buffers, for the meaning of INHIBIT-BUFFER-HOOKS.

Where "(elisp) Creating Buffers" elaborates:

     Both functions accept an optional argument INHIBIT-BUFFER-HOOKS.  If
  it is non-‘nil’, the buffer they create does not run the hooks
  ‘kill-buffer-hook’, ‘kill-buffer-query-functions’ (*note Killing
  Buffers), and ‘buffer-list-update-hook’ (*note Buffer List).  This
  avoids slowing down internal or temporary buffers that are never
  presented to users or passed on to other applications.

So while inhibit-buffer-hooks may be a slightly loose name, I think
make-indirect-buffer should nevertheless heed it for
buffer-list-update-hook as well, for the same reason this is done
everywhere else.

> So I'm not sure we want this.  What is the real-life use case behind
> this request?

The real-life use case is satisfying this bug report+patch from me,
fixing what seems like a simple oversight, and the ensuing peace of mind
that I will be grateful for, of course ;).

Thanks,

-- 
Basil

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.