RE: custom-set-variables considered harmful

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

>> ​I have been wondering about this too.  Are there any arguments for
>> not having setq run the setter of a custom option when available?
> 
> That change would create a risk of bugs in many parts of the code.
> Each differnt kind of setter function creates a different risk of
> possible errors.
> 
> That change would mean that making an ordinary let binding could run
> arbitrary Lisp code.  Unwinding the binding could also run arbitrary
> Lisp code.
> 
> Finally, it could cause errors in places that set the variable and
> expect that to do nothing but put a new value in it.  This includes
> the definitions of setter functions, right?

As I said, I don't argue for doing this.

And yes, there would need to also be a "basic setq",
which has the current behavior, to be able to use in
custom functions (e.g. setters) and some other places.
I figured that much was obvious.

The other considerations you mention are less clear to me.

I suppose another possibility might be to come up with
another function, with a short name, that does what
we're talking about: does `customize-set-variable' for
an option (except in `custom*' code) and does `setq'
otherwise.  And then encourage people to use that new
function instead of `setq' most places.  I kinda doubt
that would help much, though.

But again, I'm not proposing any of this.  I mentioned
it only as food for thought.

The problem to solve (which is admittedly a small one,
since as Stefan pointed out most options don't use
special :set functions) is that users seem to often
use `setq' for options without even being aware of
`customize-set-variable' or why it might be needed in
some cases.