RE: On obsoleting defcustoms

[Drew Adams <drew.adams@oracle.com>]

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

But are you then applying your lesson from that one
option to all of these options?  Doesn't that
contradict your previous paragraph?

(And there are likely some non-obsolete options that in
some cases have no effect.)  But see what I wrote above:
if an option no longer works then we should raise an
error when it's referenced - it should be desupported.

Obsolete should mean still works and is still supported,
but is no longer being actively developed.  Desupport
means the code supporting it is gone and we raise an
error instead.

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

It's either one or the other, no?

If it doesn't work then users deserve the runtime error.
In that case, what good is a byte-compiler message
intended to warn you to move away from using it?

If it does work, and we just want you to move away from
it, then a warning makes sense.  What are we warning
about?  The fact that it might become desupported at
some point.  That's the point of a deprecation notice
and warnings.

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

If it no longer works, yes.  But in that case we
should raise an error, not issue a compiler warning.

If it does still work then I see no reason why we'd
remove it from `customize-group'.  Especially if
`customize-option' still works etc.  This makes no
sense to me.  (Just one opinion.)

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

See above.  I don't see how that helps users.