GNU bug report logs - #53242
[PATCH] unify reads from local_var_alist

Previous Next

Full log

View this message in rfc822 format

From: Sergey Vinokurov <serg.foo <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 53242 <at> debbugs.gnu.org
Subject: bug#53242: [PATCH] unify reads from local_var_alist
Date: Fri, 14 Jan 2022 18:37:45 +0000

On 14/01/2022 08:08, Eli Zaretskii wrote:
>> Date: Fri, 14 Jan 2022 00:23:42 +0000
>> From: Sergey Vinokurov <serg.foo <at> gmail.com>
>>
>> I've noticed that local_var_alist field of the buffer structure is
>> accessed inconsistently. Sometimes it's Fassoc, sometimes it's Fassq and
>> other times it's assq_no_quit and even an explicit loop.
>>
>> I think it's safe to unify all the accesses via assq_no_quit since it's
>> an internaly maintained alist that definitely has no cycles and elements
>> are cons cells with symbol as their car.
> 
> How long can local_var_alist be?  This change will not allow the user
> to C-g from a long search.  Do we care?  How about using Fassq
> consistently instead?

This list is not directly observed by the user. The lookups happen 
during reads and writes of the buffer-local variables so if it's really 
slow the only effect user would observe is that elisp got slow. There's 
no single point for the user to C-g from.

This list definitely cannot be longer than a list of all the global 
variables ever defined. This upper bound is probably a high number, but 
not astronomically high. Perhaps if list gets really long it could be 
beneficial to use some other data structure, perhaps a hash table, instead.

Previous Next

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