Subject: bug#34765: 26.1; with-temp-buffer should not run buffer-list-update-hook

From: martin rudalics <[email-masked]>
Date: Tue, 21 May 2019 12:04:46 +0200

>>>> 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