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

[martin rudalics]

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