GNU bug report logs -
#34765
26.1; with-temp-buffer should not run buffer-list-update-hook
Previous Next
Reported by: Alexander Miller <alexanderm <at> web.de>
Date: Tue, 5 Mar 2019 22:58:02 UTC
Severity: normal
Tags: fixed
Found in version 26.1
Fixed in version 28.1
Done: "Basil L. Contovounesios" <contovob <at> tcd.ie>
Bug is archived. No further changes may be made.
Full log
Message #107 received at 34765 <at> debbugs.gnu.org (full text, mbox):
martin rudalics <rudalics <at> gmx.at> writes:
>>> 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.
> And 'get-buffer-create' should not have to worry about delving any
> deeper into the name than down to its first character to check for ' '
> or '*'.
>
> But I'm not happy with my patch anyway. Something more elegant is
> needed.
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.
Buffer names starting with spaces are already special in some contexts,
so extending that idea for inhibiting buffer hooks doesn't sound too
bad, but the extra flag seems equally elegant and more
backward-compatible. Am I missing something?
Thanks,
--
Basil
This bug report was last modified 4 years and 153 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.