unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: Philip Kaludercic <philipk@posteo.net>
Cc: "60162@debbugs.gnu.org" <60162@debbugs.gnu.org>
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	[thread overview]
Message-ID: <SJ0PR10MB5488DCCC23E2A316D55FFB63F3E79@SJ0PR10MB5488.namprd10.prod.outlook.com> (raw)
In-Reply-To: <87y1r56hbo.fsf@posteo.net>

> `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	other threads:[~2022-12-17 20:53 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-17 16:35 bug#60162: [PATCH] * lisp/cus-edit.el (setopt--set): Warn instead of rasing an error Philip Kaludercic
2022-12-17 17:40 ` Drew Adams
2022-12-17 18:00   ` Philip Kaludercic
2022-12-17 20:53     ` Drew Adams [this message]
2022-12-17 22:19       ` Philip Kaludercic
2022-12-18 11:28 ` Eli Zaretskii
2022-12-18 11:46   ` Philip Kaludercic

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=SJ0PR10MB5488DCCC23E2A316D55FFB63F3E79@SJ0PR10MB5488.namprd10.prod.outlook.com \
    --to=drew.adams@oracle.com \
    --cc=60162@debbugs.gnu.org \
    --cc=philipk@posteo.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).