bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#21695: 25.0.50; Change most occurrences of `setq' in Emacs manual to


From: Eli Zaretskii
Subject: bug#21695: 25.0.50; Change most occurrences of `setq' in Emacs manual to `customize-set-variable'? Really?
Date: Sun, 12 Sep 2021 12:37:49 +0300

> Date: Sun, 12 Sep 2021 09:30:21 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: larsi@gnus.org, 21695@debbugs.gnu.org, hmelman@gmail.com, rms@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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]