RE: Deprecate _emacs on Windows

["Stephen J. Turnbull" <stephen@xemacs.org>]

Drew Adams writes:

 > So you are _not_ saying that in your experience - in all the
 > projects you know of - there was ever _actually_ a warning message
 > used to convey a deprecation notice.

Hm?  Maybe you should go into reading tea leaves instead of
emacs-devel.  You could make a lot of money with that kind of creative
interpretation.

 > That's an opinion, an interpretation of the meaning of deprecation.

No, it's not *merely* an opinion, it's the official policy of the
Python project.  Google for "DeprecationWarning" and
"PendingDeprecationWarning" and read PEP 5.  (It's short.)

 > > Formal deprecation is a policy statement that this feature
 > > should *not* be used, 
 > 
 > in the future (deprecation is not desupport; it precedes desupport)

Yes, of course that is the relationship between deprecation and
desupport, but there are other consequences of deprecation, in
general.  Deprecated functionality is normally not considered to
warrant support when implementing new features.  It is also often the
case that deprecated features *are* dangerous or buggy-by-design.

Again, it seems to me that you are objecting to accompanying
deprecation with a warning because you thing it's overblown *in this
case*.  I think there is a good rule of thumb: if a feature is not so
bad as to warrant an obtrusive deprecation warning, then it's probably
not worth deprecating.

 > > and yes, that should indeed get a warning.
 > 
 > No, that doesn't follow at all.

Of course it doesn't follow.  It's a policy, more or less arbitrary.
Here, "should indeed" *is* my opinion.

 > What danger are you warning users about?

It happens that three days ago, due to a change someone made in
XEmacs, my init file failed to get loaded.  I was *pissed*.  Another
example: somebody who depends on the init file to set up accessibility
features could be crippled.  Yes, I think this is important enough to
warn people who use this feature.

I infer you think that users should read NEWS.  That's a reasonable
opinion, but one I disagree with, and one many users take *strong*
exception to.  They do not want to read NEWS to continue using an
upgraded program as they are accustomed to.

 > But deprecation in general, as a rule, is not accompanied by
 > WARNINGs.

Of course it is.  Compilers issue warnings all the time about
deprecated features and usages.  That's what they're called,
"warnings".

It's true that in my experience UIs rarely issue deprecation warnings,
but that's mostly because the programs I use almost never deprecate
features that are part of the UI.  They just add new UI.  The only
case I can remember was when XEmacs decided to move from supporting
both the "Emacs" application class and the "XEmacs" application class
in the X resource database to supporting "XEmacs" only.  In that case
we explicitly decided not to warn because it seemed likely that most
people with "Emacs" in their .Xresources would have it there because
they use Emacs as well as XEmacs, so it was inherently ambiguous as to
whether the user needed to be informed -- even once the feature is
removed from XEmacs, it is still needed for use with Emacs.

 > Are you trying to make [the deprecation decision into an issue] again?

No.  You're being exceptionally tendentious this week, Drew.