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

[Drew Adams <drew.adams@oracle.com>]

>> Searching emacs 27.2 elisp source I find about 400 hits for :set.
> 
> That is more than I expected.  However, there around 8000 defcustoms
> in master as of May 11, and only 462 instances of :set.

Numbers are good to have.  But we've said from the
beginning that a small minority of defcustoms use
:set.  That's 6%, which doesn't surprise me at all.

(Of course that checks only code that's part of
Emacs as distributed, not 3rd-party code.  But I
expect the proportion to be even smaller there.)

> Telling people to use customize-set-variable for all 8000 of them
> feels like the tail wagging the dog.

No one, I think, has suggested that users should
privilege using Lisp to set user options.  I said
we should recommend that they use the Customize UI.

For users who do sometimes use Lisp for that, no
one has suggested that they customize all 8000
options.  What was suggested is that for Lisp use
it's appropriate to use `customize-set-variable',
not `setq'.

> I have a feeling that most of those 462 with :set actually require
> that people use customize-set-variable to set them in the init file.

Why that feeling?  Why not a feeling that :set and
:initialize are there mainly with the expectation
that users use the Customize UI?

> I suspect that, for most of them, :set is meant to handle the case
> where you change the setting once the feature is already in use.

Why do you suspect that?  And what difference does
it make when (or why) you change the value?  Maybe
I'm missing something here - could you elaborate?

> I think that if we eliminate these, we will get a much smaller
> number of exceptions, and we could find a nicer way to handle them.

Again, I'm not clear about what you're saying, or
why.  I guess you mean eliminate the use of :set
in some of those defcustoms that use it?

> But even with 462 exceptions, it could be easy enough to warn about
> setting one of those in .emacs with setq.

I don't think that's the right approach, but I
hear you.  (Eli spoke to the use of warnings for
init-file loading.)
________


I suggest that we create a short alias, such as
`cset' for `customize-set-variable' - for "set
custom variable".

And I suggest that we recommend, for options,
that users use, in order of priority/favor:

 1. The Customize UI.
 2 `cset' if they don't use the UI.

Simple.  Both just DTRT for options.  No gotcha.

And I suggest that we motivate this by telling
users why - tell them that setting some options
requires additional behavior, besides just
setting the value (i.e., besides `setq').

Not the end of the world for users who don't
read or follow that recommendation - just what we
have now (gotchas in a small minority of cases).

And I recommend that the doc examples that use
`setq' with user options be changed to use `cset'.

I don't think this is a radical or cumbersome
proposal.  Others can disagree, of course.  If
implemented, who would be bothered by it, in
practice?  Not those who would continue to use
`setq' with options, I expect.

How much doc would actually need to be fixed?
Likely very little, but it would mean checking
occurrences of `setq'.  How many example
occurrences involve options?  I expect few.
___

Here's another alternative (I'm _not_ suggesting
it):

`customize-set-variable' in fact does just a
`set' if applied to a non-option.  This means
that `set' and `setq' could do just that, i.e.,
they could take care of the option case.

Looking at the code for `customize-set-variable',
it seems like is should first test whether the
arg is in fact an option, before doing a bunch
of custom stuff.  Maybe I'm misreading, and
there's no quicker way.

Or maybe `customize-set-variable' should _not_
set non-options?  Maybe it should raise an error
for a non-option?  (Someone will say that's not
backward-compatible...)
___

Anyway, I remind everyone posting in this thread
that the bug was already summarily dismissed
("won't fix").