GNU bug report logs - #34765
26.1; with-temp-buffer should not run buffer-list-update-hook

Previous Next

Full log

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

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 34765 <at> debbugs.gnu.org, alexanderm <at> web.de, monnier <at> IRO.UMontreal.CA
Subject: Re: bug#34765: 26.1; with-temp-buffer should not run
 buffer-list-update-hook
Date: Sat, 27 Apr 2019 10:30:43 +0200

> 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

Previous Next

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