GNU bug report logs -
#21695
25.0.50; Change most occurrences of `setq' in Emacs manual to `customize-set-variable'
Previous Next
Reported by: Drew Adams <drew.adams <at> oracle.com>
Date: Fri, 16 Oct 2015 21:51:01 UTC
Severity: wishlist
Found in version 25.0.50
Done: Lars Ingebrigtsen <larsi <at> gnus.org>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
> Date: Sun, 12 Sep 2021 09:30:21 +0000
> From: Gregory Heytings <gregory <at> heytings.org>
> cc: larsi <at> gnus.org, 21695 <at> debbugs.gnu.org, hmelman <at> gmail.com, rms <at> gnu.org
>
> > What will happen if setq is in the user's init file? We generally delay
> > warnings until after the startup in those cases.
> >
>
> With the following .emacs:
>
> (require 'allout)
> (setq allout-auto-activation t)
>
> a warning is displayed, but I don't know if this is during of after the
> startup. At least it is visible when startup has completed.
You need a much larger init file with several setq like this. The
warnings usually fly by you without giving enough chance to read them.
> > Also, warnings.el is not preloaded, so this call could barf in some
> > valid cases.
> >
>
> That's not what I see:
>
> ;;;###autoload
> (defun display-warning (type message &optional level buffer-name)
That's autoloaded, not preloaded; the latter is in loadup.el.
> > And finally, do we really want to slow down each setq by calling intern
> > and Fget? setq is many times used inside tight loops. I'm not sure the
> > resulting run-time penalty is justified. Did you measure the effect of
> > this on performance?
> >
>
> With the updated patch, on my laptop, the execution of setq takes ~48
> nanoseconds instead of ~40 nanoseconds. Which seems reasonable.
Is this multiplicative, i.e. if you perform it many times, does it
indeed take 20% longer overall? If so, this is not an acceptable
performance hit, I think, not for such a minor feature.
This bug report was last modified 3 years and 302 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.