bug#21695: 25.0.50; Change most occurrences of `setq' in Emacs manual to `customize-set-variable'? Really?

[Eli Zaretskii]

> Date: Sun, 12 Sep 2021 08:23:01 +0000
> From: Gregory Heytings <gregory@heytings.org>
> Cc: 21695@debbugs.gnu.org, hmelman@gmail.com, Richard Stallman <rms@gnu.org>
> 
> +--
> +** '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.

> --- a/src/eval.c
> +++ b/src/eval.c
> @@ -525,8 +525,15 @@ usage: (setq [SYM VAL]...)  */)
>          : Qnil);
>        if (!NILP (lex_binding))
>       XSETCDR (lex_binding, val); /* SYM is lexically bound.  */
> -      else
> +      else {
> +     if (!NILP (Fget (sym, intern ("custom-set"))))
> +       call2 (intern ("display-warning"), intern ("setq"),
> +              CALLN (Fformat,
> +                     build_string
> +                     ("`%s' should be set with `customize-set-variable'"),
> +                     sym));
>       Fset (sym, val);        /* SYM is dynamically bound.  */
> +      }

What will happen if setq is in the user's init file?  We generally
delay warnings until after the startup in those cases.

Also, warnings.el is not preloaded, so this call could barf in some
valid cases.  OTOH, setq is a primitive written in C, so ther should
be no need to call intern for it.

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?