GNU bug report logs -
#48264
28.0.50; Changing the default for DEFVAR_PER_BUFFER variables takes O(#buffers) time
Previous Next
Full log
Message #101 received at 48264 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Spencer Baugh <sbaugh <at> catern.com>
>> Date: Thu, 6 May 2021 17:33:38 -0400
>> Cc: Spencer Baugh <sbaugh <at> catern.com>
>>
>> For buffer variables without a default, we still use BVAR. For any
>> buffer variable with a default, we use BVAR_OR_DEFAULT. A later
>> commit will statically enforce this.
>
> This part says they are the same:
>
>> --- a/src/buffer.h
>> +++ b/src/buffer.h
>> @@ -284,6 +284,8 @@ struct buffer_text
>>
>> #define BVAR(buf, field) ((buf)->field ## _)
>>
>> +#define BVAR_OR_DEFAULT(buf, field) BVAR (buf, field)
>
> What am I missing here?
The commit message is accurate - we indeed use BVAR for buffer variables
without a default, and BVAR_OR_DEFAULT for buffer variables with a
default.
It's just that in this commit, those two behave identically. The
immediate next commit makes them different.
I split it up in this way because this commit is the result of a big
tree-wide sed, no actual meaningful change; I think it's much easier to
understand the next commit when the two are kept separate.
> Also, I have a question: suppose we have a variable that is defined
> with DEFVAR_LISP, and then some Lisp calls make-variable-buffer-local:
> how will that work with these two macros when the C code needs to
> access the buffer-local value?
Nothing in these changes affect variables that are made into
buffer-locals from Lisp code; these changes only affect variables
built-in to Emacs that were defined with DEFVAR_PER_BUFFER. So that
will just work the same as it does today - accesses to such variables
don't go through BVAR today.
This bug report was last modified 2 years and 289 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.