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

[Gregory Heytings]

> > That being said, I would say that using (setq latin1-display t) when 
> > latin1-display has a :set is always a bug, in the init file, 
> > interactively, or in built-in code (bytecompiled or not), and that (set 
> > 'latin1-display t) should be used instead.  WDYT?
>
> I have not studied the code -- I just picked a variable at random.  The 
> point is that code in a package will commonly use setq on the user 
> options to implement the code, and this is how it should be.

My point is that code that sets a user option that has a :set should set 
it with (set 'foo val) instead of (setq foo val).

I just checked: on the current trunk, there are 331 defcustoms with a 
:set.  Out of these, only 49 are set with setq, 33 only at one place, and 
16 more than once.  That would require changing 85 setq's into set's.

> (Also note that your patch will issue a bunch of warnings if the user 
> does an `eval-buffer' after loading .emacs into a buffer and then 
> evaling it (in a running Emacs).)

There are not that many custom variables that will behave differently when 
the init file is first loaded and when it is eval-buffer'd.  AFAICS this 
will only happen for variables whose files have been loaded in the 
meantime after they have been setq'd.