Thanks for your work on Emacs, On Sat, Jan 15, 2022, 05:42 Sergey Vinokurov 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!