bug#60162: [PATCH] * lisp/cus-edit.el (setopt--set): Warn instead of rasing an error

[Philip Kaludercic <philipk@posteo.net>]

Drew Adams <drew.adams@oracle.com> writes:

>> `customize-set-variable' isn't used at all,
>> to prevent modifying the user theme.  
>
> 1. Why?
>
> Why should the two differ wrt whether theme `user'
> gets modified?  Why does updating that theme make
> sense in the one case but not in the other?

If a user option is added to the user theme, then this "pollutes" the
`custom-set-variables' block which is IMHO pointless, since the
changes are usually already made programmaticaly, so double-saving them
will usually cause more fuss than be of any use.

> 2. And now that this is brought to my attention, I
> really wonder why `customize-set-variable' pushes
> the new setting to the `user' theme.

So that it is clear what option have to be saved, when customised using
the Easy Customization Interface.

> AFAIK, there's nothing at all that requires, or that
> should assume, that that function is called by the
> current user, or that even if it is, that that user
> wants theme `user' updated that way.
>
> This is apparently the case at least since Emacs 22.
> Emacs 20 had no custom themes, and I don't have the
> source for Emacs 21.  But a guess is that whoever
> (Chong Yidong?) added custom themes to Emacs decided
> to add this to `customize-set-variable'.
>
> 3. Why is modifying theme `user' a good idea for any
> function that changes an option value?  Especially,
> why should that be hardcoded (i.e., not an optional
> parameter)?

You mean why "user" and not some other theme?

> I see that we modify themes when a _face_ is changed
> with `face-spec-set' (via `face-spec-recalc').  But
> I don't see that we do that if you instead use
> `set-face-attribute' or similar.  What criteria decide
> whether to modify themes when a face gets modified?
>
> 5. Does the Emacs 29 manual call out this difference
> between `setopt' and `customize-set-variable'?  I see
> it only in your email, not in the doc strings or the
> code comments (in what you included in your mail).

(What happened to 4?)

It isn't mentioned in either the Emacs or the Elisp manual.

> 6. Coming back to your fix: why is warning instead
> of raising an error TRT?  You say it's to be able to
> continue loading an init file.  Do we do that with
> other attempts to set a user option/face to a bad
> value when loading code?  I think not.  For
> `customize-set-variable', `customize-set-value', and
> `setq'/`set' we issue no warning and raise no error.
>
> Runtime "warnings" are generally a _bad_ idea, IMO.
> Even "warnings" during code loading are a bad idea.
> My suggestion is to either raise an error or do what
> `customize-set-variable' and the rest do, which is
> set the value and ignore whether it might be bad -
> don't even test it.

Well an error is already being raised, but as I said, it is my
impressions this is too strict.  Typing mistakes in regards to user
options aren't great, but certainly shouldn't be fatal.  Or I haven't
ever regarded them as something reliable enough to just assume will
always hold -- after all, you can bypass the type checking.  The initial
version of the macro didn't even have type-checking.  It was added later
as a convenience feature to assist the user and inform them if a mistake
was made but also to incentivise package developers to add types to user
options.

> ___
>
> `setopt' was added for Emacs 29, which isn't out yet.
> Is the behavior appropriate?  What's the rationale,
> besides not having to quote and allowing for multiple
> settings?  Other than quoting, why should it behave
> differently from `customize-set-variable'?