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

Previous Next

Full log

Message #34 received at 53242 <at> debbugs.gnu.org (full text, mbox):

From: Corwin Brust <corwin <at> bru.st>
To: Sergey Vinokurov <serg.foo <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 53242 <at> debbugs.gnu.org
Subject: Re: bug#53242: [PATCH] unify reads from local_var_alist
Date: Sat, 15 Jan 2022 10:02:31 -0600

[Message part 1 (text/plain, inline)]

Thanks for your work on Emacs,

On Sat, Jan 15, 2022, 05:42 Sergey Vinokurov <serg.foo <at> 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!

[Message part 2 (text/html, inline)]

Previous Next

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