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

[Gregory Heytings]

> everything else in this discussion seems to support the opposite 
> conclusion: setting one of these variables with setq in an init file, in 
> the usual simple case (you haven't loaded the definition yet), is 
> perfectly ok.

Understanding statements always requires some context.  Using setq on a 
variable that hasn't been loaded is indeed okay, but that does not 
contradict what Martin said, because a variable that hasn't been loaded 
never has a :set form (even if its definition contains a :set form).  In 
summary:

1. 'foo' does not have a :set form in its definition => it's okay to set 
it with setq, no warning is displayed

2. 'foo' has a :set form in its definition, but its definition hasn't been 
loaded => it's okay to set it with setq, no warning is displayed

3. 'foo' has a :set form in its definition, and its definition has been 
loaded => it's a bug to set it with setq, a warning is displayed

There are a number of corner cases that are not covered by the above 
description, however:

1. if you eval-buffer your init file during an Emacs session, definitions 
have been loaded in the meantime, so you get warnings you didn't get when 
you started Emacs; are these legitimate warnings?

2. if you byte-compile your init file, setq's become set's, so the 
warnings you would see with your non-byte-compiled init files are not 
displayed anymore; should they be displayed?

3. in (some) files in which variables with a :set form are defined, setq 
is used to set them (which means that warnings would be displayed if they 
were eval-buffer'd or loaded without byte-compiling them); are these 
legitimate warnings? is it a bug to use setq in those files?