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>]

> > Telling people to use customize-set-variable for all 8000 of them
> > feels like the tail wagging the dog.
> 
> Yes.  But I don't see why the numbers matter here.

I agree.

> An option which cannot be usefully change via setq
> mentions that in its doc string (or at least it
> should; if it doesn't, that's a documentation bug),

Yes, but what about 3rd-party code that doesn't
bother saying that in doc strings?  Sure, it's
wrong; but does that recommendation solve the
problem?

> so all we need to say in the manual is that such
> options exist, and they announce the need to use
> customize-set-variable in their doc string by
> such-and-such text.  Then the users will have
> enough information to figure out which variable
> needs what method.

See above, about 3rd-party code.

And that approach requires users to be on the
lookout for this.

That's a bit like not having stop signs and
just telling people to always look both ways
before going through an intersection.  Sure,
they've been warned.  But they then need to
check every intersection, even if there are
few cars on the crossroads.  And it's little
comfort after an incident to be say "Told
you to watch out."

> > 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.
> > 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.
> 
> That's an orthogonal issue, I think.  The issue at hand is how to
> prevent users from mistakenly using setq where doing that is
> insufficient.  We could independently see to it that the number of
> options that actually need this is kept at a minimum.

Agreed.