RE: On obsoleting defcustoms

[Drew Adams]

> > 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.
> 
> Is "desupported" defined in Emacs development?  Searching online, I
> was only able to find that word used in reference to Oracle Database.

No idea, and I don't care what terms we use.

There's often (usually?) a distinction between these 3
levels of support (these are descriptions, not names):

1. Actively supported and developed.  If you file a
   bug or suggest an enhancement it will likely be
   looked at, at some point.

2. Not actively supported and developed, but still in
   the code, still working (but support for fixing bugs
   may not be there or may be reduced), and maybe even
   still documented to some extent.

3. Not supported at all.  Doesn't work.  Not in the code.
   Not documented (except old doc out on the wild web).

Each is a gray area, and different organizations have
different policies and draw lines in different places.

In principle, at least, #2 is transitional, or at least
users are told that the feature _might_ at some point
in the future change to status #3.  Things may continue
to work, but you're recommended to use the preferred
alternative/replacement (if any).

Since in #3 the feature is absent - doesn't work, you
generally get an error if you try somehow to use it.

The transition from #1 to #2 is sometimes called
deprecation, and in #2 the feature is sometimes called
obsolete or deprecated.  In #3, the feature no longer
exists, and it's sometimes said to be unsupported.
The transition from #2 to #3 is sometimes called
desupport.

There's no obligation to move from #2 to #3, BTW.  At
least in business, where there can be particularly
important customers, some features may be deprecated
(move to #2) with no intention or expectation that they
will ever really be moved to #3.

Users might not be told that, however, since the idea
is to get them to abandon the deprecated feature.
But some considerations can come into play that make
it impossible or undesirable to ever really remove a
feature altogether.

> I think we talk about "making obsolete" and "removing" a
> variable/function/face, and their definitions are:
> 
> a) Obsolete means the byte-compiler warns about their use
> b) Removed means it no longer exists

OK, that sounds to me like #2 and #3, respectively.

> Note that we have many obsolete variables that are declared to be "no
> longer used", that is, they have no effect.  You are free to argue
> against the status quo, of course, but that is what we have.

Maybe so.

We also have lots of stuff that's called obsolete and
that still works - thank goodness, IMO!  It may no
longer be used much by the distributed Emacs code, but
it may well still be used by Emacs users.

And even if an obsolete feature is no longer used, that
doesn't necessarily mean that it would have no effect
if someone did use it.

If something really has no effect then there's no reason
to warn about using it.  There may be, and often is, a
reason to retain code that just raises an error for
something that's unsupported (which isn't quite the same
thing as having no effect, but it's at least not having
the expected effect).

> > If it doesn't work then users deserve the runtime error.
> 
> I don't think raising a run-time error is wise just because we decided
> that a variable should have no effect.  That would mean gratuitously
> breaking code that might otherwise be working.  It is better to allow
> for a grace period by raising an obsoletion warning.

It sounds like we maybe have different understandings
of "have no effect".

A variable that has no effect isn't a variable.  It's
not even an unbound variable.  But yes, if you want to
remove a variable from having its formerly expected
effect, then unbind it so users get an unbound error.

A variable that continues to have its expected effect,
or at least some semblance of that, and that you're
warned/recommended not to continue to use, is just
obsolete - it's not yet missing/removed.

> > I don't see how that helps users.
> 
> The point IMO is that advertising features that we are planning to
> remove does not help users.  On the contrary, we should recommend
> moving away from obsolete features.

Yes, a warning is appropriate in that case.  Removing
the feature is something else.

You're keeping `customize-option' for such a variable,
but you're removing it from `customize-group'.  To me
that's not a great approach, but it's not a big deal.

And I wouldn't call keeping either of those customize
possibilities "advertising".  If you remove the
possibility of using an option as an option, i.e.,
remove its usual customization, then you've removed
more than advertising.

OK, you've only removed some, not all, possibilities
of customizing - just `customize-group', I guess.
You did that to reduce noise in the group UI.  That's
understandable.  I suggested instead keeping the
obsolete options in the group but showing warnings
there for them.  Not a big deal anyway.

These things aren't hard & fast rules.  They're
judgment calls.  And opinions can differ.