Re: Obsoleting more progressively

[Glenn Morris]

FWIW, I suspect much of the problem you are trying to solve is due to
no-one paying attention to the warnings. Either because the package is
unmaintained but still in use, so there is no-one there to deal with
the warnings (eg recent old-style backquotes stuff), in which case
trying to make it fail more gradually makes no difference to the final
result; or because people just ignore the warnings.

So I agree with the suggestion that the best way to deal with this is
to make the warnings _mean_ something; ie actually remove obsolete
stuff in a timely fashion, not drag it out for still longer.

Anyway, having said that:

Stefan Monnier wrote:

> - Add warnings at runtime when obsolete stuff is used.

> - Actually remove the function/variable from the non-released code.
>   I.e. remove/deactivate the functions/variables from trunk during
>   development but put them back in when we start pretesting.

You could combine 1 with 2 by having some flag that says whether using
an obsolete thing triggers an error or a warning. Set it to error
during development, and to warning for a release.

Un-thought-out plan: when compiling foo.el, put a comment marker at
the end of the file giving the obsolescence version of the oldest
obsolete feature that it uses (if any).

When loading foo.elc, give an error or warning if the marker indicates
that a very obsolete feature is used (Eg "This file uses features that
were obsolete in Emacs 21"). Disable the warning if foo.el has been
added to some list variable
i-know-that-this-file-uses-obsolete-code-and-will-break-soon. (If it
is controlled by a global switch people will just turn it off and
forget about it.)

Comedy option: parse foo.el for a maintainer address, have the
byte-compiler spam the maintainer every time the file is compiled.