bug#49160: 28.0.50; [PATCH] Uninitialized inhibit_buffer_hooks

[Basil L. Contovounesios]

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

>> From: "Basil L. Contovounesios" <contovob@tcd.ie>
>> Cc: Eli Zaretskii <eliz@gnu.org>,  49160@debbugs.gnu.org,  dick
>>  <dick.r.chiang@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