bug#53242: [PATCH] unify reads from local_var_alist

[Corwin Brust <corwin@bru.st>]

[-- Attachment #1: Type: text/plain, Size: 1877 bytes --]

Thanks for your work on Emacs,

On Sat, Jan 15, 2022, 05:42 Sergey Vinokurov <serg.foo@gmail.com> wrote:

> On 15/01/2022 07:32, Eli Zaretskii wrote:
> >> My argument is that at this point we don't care whether user is able
> >> to interrupt basic operations of reading and writing buffer-local
> >> variables.
>

This is my view also, fwiw.  Please consider the case of a package
developer who may be abusing buffer-local vars during experiments.  It
seems this will cause much more ’oops, time to kill Emacs/grab a coffee'.


I agree with your position but see a more further-reaching conclusion.
>
If there's a risk of the list being really long the Emacs can employ a
> different data structure, e.g. a hash table, to make reads and writes of
> variables fast regardless of the number of entries. In my opinion such a
> change would serve users even better as there would be no need to
> interrupt any slow operations because there would be none.
>


I tried to follow this conversation but it wasn't clear to me what out
motive is for this change.

I had understood we typically make (especially in the c sources) our
changes to achieve specific, tangible improvement.  Is that the case here?
is the particularly oppressive 'tech debt'?  In the latter case, does
history reflect consideration wrt the original selections in each of the
various cases we hereby change?

Also (and especially if we must 'clean for the sake of cleanliness'), could
we prefer the (seeming more conservative of UX) interruptable varient in
this case?  (Is that very costly? How costly and how have we measured that?)

It would be comforting if sweeping changes could be accompanied by analysis
of the impacted sources.  (We clearly deliberately chose interruptable
search in some cases and not others to date.  Why?)

Thanks so very much for Emacs!

[-- Attachment #2: Type: text/html, Size: 2882 bytes --]