bug-gnu-emacs
[Top][All Lists]
Advanced

[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: Drew Adams
Subject: bug#60162: [PATCH] * lisp/cus-edit.el (setopt--set): Warn instead of rasing an error
Date: Sat, 17 Dec 2022 20:53:43 +0000

> `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?

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.

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)?

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).

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.

___

`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'?





reply via email to

[Prev in Thread] Current Thread [Next in Thread]