[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#60162: [PATCH] * lisp/cus-edit.el (setopt--set): Warn instead of ras
From: |
Philip Kaludercic |
Subject: |
bug#60162: [PATCH] * lisp/cus-edit.el (setopt--set): Warn instead of rasing an error |
Date: |
Sat, 17 Dec 2022 22:19:03 +0000 |
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'?