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: Gregory Heytings
Subject: bug#21695: 25.0.50; Change most occurrences of `setq' in Emacs manual to `customize-set-variable'? Really?
Date: Sun, 12 Sep 2021 09:30:21 +0000


+** 'setq' displays a warning when 'customize-set-variable' should have been 
used.
+Some custom variables need to be set with 'customize-set-variable', because
+they were designed to be set through the Customization interface and have a
+:set lambda form which does other things after they have been set.

I thought the conclusion was that most variables with :set can be safely set by setq, isn't that so? If so, these warnings will mostly annoy.


No, that wasn't the conclusion. Most variable with :set can safely be set by setq *before* the file in which they are declared is loaded. And no warnings are displayed in that case. But all variables with :set cannot be safely be set by setq *after* the file in which they are declared has been loaded. And warnings are displayed in that case.


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.


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)


OTOH, setq is a primitive written in C, so ther should be no need to call intern for it.


Okay, updated patch attached.


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.

Attachment: Warn-when-custom-variable-is-wrongly-set.patch
Description: Text Data


reply via email to

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