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

Previous Next

Full log

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

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

> Date: Fri, 14 Jan 2022 18:37:45 +0000
> Cc: 53242 <at> debbugs.gnu.org
> From: Sergey Vinokurov <serg.foo <at> gmail.com>
> 
> > 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.

?? What do you mean?  Long operations in Emacs generally periodically
check for user's quitting, andif they detect C-g, they throw to
top-level.  assq_no_quit doesn't.

> 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.

The question I asked was: it high enough to cause annoyingly long
operations in some cases, and whether we care that users will no
longer be able to interrupt such long operations.  You seem to assume
that the number cannot be high enough, but I see no basis for that
assumption in what you wrote.

Previous Next

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