emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: On obsoleting defcustoms


From: Stefan Kangas
Subject: RE: On obsoleting defcustoms
Date: Thu, 12 Nov 2020 19:07:44 -0500

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

>> That's what we do now.  See `M-x customize-group RET browse-url RET'
>
> I don't see any such warnings/messages there, until you
> open the full doc string of an option.

We have the face `custom-variable-obsolete', but indeed the warning is
unfortunately only made explicit on the help screen.

>> in Emacs 27 for a bad case of what that might look like.
>
> What's bad about it?

There are more obsolete options than relevant ones.  (Including, e.g.,
the options for the now wildly irrelevant Mosaic browser.)

> If all of those options still "work", a user should be
> able to make use of Customize to change their values.
>
> And if they don't work then there should be no supporting
> code, and they'd be unrecognized - raise an error if
> referenced in any way.  Typically, deprecated/obsolete !=
> unsupported.  Does Emacs take the point of view that all
> of this is unsupported?  If so, remove its code, so using
> raises an error.

The problem is that, AFAICT, it is not really feasible to have a
one-size-fits-all for how we go about deprecating options.  In some
cases it makes sense for them to continue to have effect during the
obsoletion period, but in other cases it does not.

I for one was bitten by this trying to customize an option that turned
out to simply no longer have any effect.  Should it have just been
removed in this case?  Well, it would of course have helped me.  But
third-party code that tried to use it would get the signal "Symbol's
value as variable is void" at run-time, instead of the much gentler
byte-compiler warning that it is obsolete.

Not showing it in `M-x customize-group' seems like a good compromise.

> What's not fine, IMO, is to remove it from Customize.  If
> something is removed from Customize then it's not the case
> that it's still usable with Customize (or Customize is
> still usable for it).

The current proposal as discussed in the bug will keep both
`customize-option' and `customize-saved'.  So you can still customize
them using customize.



reply via email to

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