From: "Drew Adams" <drew.adams@oracle.com>
To: "'Stephen J. Turnbull'" <stephen@xemacs.org>
Cc: 'Juanma Barranquero' <lekktu@gmail.com>,
'Lennart Borgman' <lennart.borgman@gmail.com>,
'Stefan Monnier' <monnier@iro.umontreal.ca>,
'Emacs developers' <emacs-devel@gnu.org>
Subject: RE: Deprecate _emacs on Windows
Date: Wed, 23 Mar 2011 07:09:48 -0700 [thread overview]
Message-ID: <9BB0B675F0A64762BC3FDBD9A9B02C1A@us.oracle.com> (raw)
In-Reply-To: <87pqpi8qui.fsf@uwakimon.sk.tsukuba.ac.jp>
> > I objected to _warning_ users simply because you are deprecating
> > `_emacs'.
>
> In all the projects I know of, your understanding of "how deprecation
> is done" notwithstanding, deprecation's semantic content is issuing a
> warning.
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. You are merely claiming that "semantically" a deprecation amounts to
warning the user about something.
That's an opinion, an interpretation of the meaning of deprecation. It's also
akin to Juanma's "danger of misunderstanding" or not hearing about the
deprecation. The question is what you are really warning the user about if
deprecation, by definition, implies warning, as you suggest.
Certainly a deprecation notice informs the user of something, and often
something that might have important consequences. No one is saying that a
deprecation notice isn't important.
The question is whether any of those consequences constitute a danger. If so,
then I would agree that _that_ particular deprecation notice should be
accompanied by a warning of the specific danger. It doesn't follow that all
deprecations imply some potential danger.
> Formal deprecation is a policy statement that this feature
> should *not* be used,
in the future (deprecation is not desupport; it precedes desupport)
> *will* be removed,
yes "will", at some point in the future
> and any current uses should be ported to the appropriate idiom,
Agreed - all of that.
> and yes, that should indeed get a warning.
No, that doesn't follow at all.
What danger are you warning users about?
> > That's not something to warn about. There is no danger.
>
> OK, Drew, put
> (if (< (random 100) 1) (error "Your .emacs is no longer usable."))
> as the first line in your .emacs. When it triggers, come back and
> tell us how you happy you are about losing use of your init file
> without warning until it actually happens.
Informing users is not warning them. A deprecation notice is typically next to
the relevant material in the doc, and is often in release notes (e.g. NEWS) as
well.
Check your favorite (after Emacs) software's API doc for notice that some
routine or use of some parameter or some such is deprecated as of release XYZ.
Now look to see if the top level of that software screams at you when you invoke
it, letting you know all of the packages, routines, parameters, etc. that have
been deprecated. Doesn't happen, in general.
Yes, of course, if something is super-important, it might well be called out
additionally in a prominent place or two (typically release notes). And yes, if
some _real danger_ is involved, then a warning about that danger will be placed
in well chosen places. But deprecation in general, as a rule, is not
accompanied by WARNINGs.
(You might find other pseudo-warnings occasionally: warnings in name only
(WINO). But I don't see even those in the doc that I use.)
> Just how often do you think long-time users read the section about
> what the name of the init file is, anyway? Or NEWS?
I'm not worried about it, frankly, and I'm one of those users. Depends how
important you think this renaming is, I guess.
In any case, wanting users to be sure they get the message is one thing.
Scaring them with a WARNING is another thing. You are not warning them about
anything in particular in this case - not AFAICT.
> The issue really *is* whether the feature should be removed,
Then in your opinion *that* should be the discussion: whether _emacs should be
deprecated. But that has already been decided, so it is no longer an issue.
Are you trying to make it one again?
> and therefore deprecation and the accompanying warning are warranted,
If whether _emacs should be deprecated is still an issue, as you say, then it
does _not_ follow that the deprecation and warning are warranted.
Anyway, nothing says that a given deprecation notice should be accompanied by a
warning. Some deprecations yes, but not in general.
> Personally, I think _emacs is harmless, and deprecating it is
> indeed crying wolf, but that's not my decision.
We agree about that, at least.
next prev parent reply other threads:[~2011-03-23 14:09 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-12 21:54 Deprecate _emacs on Windows Juanma Barranquero
2011-03-12 22:02 ` Lennart Borgman
2011-03-12 22:48 ` Drew Adams
2011-03-12 22:53 ` Lennart Borgman
2011-03-12 23:03 ` Drew Adams
2011-03-12 23:20 ` Lennart Borgman
2011-03-13 4:01 ` Stefan Monnier
2011-03-13 4:14 ` Juanma Barranquero
2011-03-22 20:38 ` Drew Adams
2011-03-22 20:50 ` Juanma Barranquero
2011-03-23 0:12 ` Drew Adams
2011-03-23 0:26 ` Juanma Barranquero
2011-03-23 0:58 ` Drew Adams
2011-03-23 1:34 ` Juanma Barranquero
2011-03-23 1:42 ` Juanma Barranquero
2011-03-24 23:33 ` Stephen J. Turnbull
2011-03-24 23:39 ` Juanma Barranquero
2011-03-23 2:42 ` Drew Adams
2011-03-23 3:00 ` Juanma Barranquero
2011-03-23 3:20 ` Stephen J. Turnbull
2011-03-23 3:34 ` Juanma Barranquero
2011-03-23 5:01 ` Óscar Fuentes
2011-03-23 12:07 ` Juanma Barranquero
2011-03-23 12:23 ` Fabian Ezequiel Gallina
2011-03-23 12:30 ` Juanma Barranquero
2011-03-23 13:36 ` Fabian Ezequiel Gallina
2011-03-23 13:42 ` Drew Adams
2011-03-23 14:30 ` Juanma Barranquero
2011-03-23 17:40 ` Stefan Monnier
2011-03-23 14:09 ` Drew Adams [this message]
2011-03-23 16:23 ` Stephen J. Turnbull
2011-03-13 22:49 ` Chong Yidong
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9BB0B675F0A64762BC3FDBD9A9B02C1A@us.oracle.com \
--to=drew.adams@oracle.com \
--cc=emacs-devel@gnu.org \
--cc=lekktu@gmail.com \
--cc=lennart.borgman@gmail.com \
--cc=monnier@iro.umontreal.ca \
--cc=stephen@xemacs.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).