From: "Drew Adams" <drew.adams@oracle.com>
To: "'Juanma Barranquero'" <lekktu@gmail.com>
Cc: '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: Tue, 22 Mar 2011 17:58:23 -0700 [thread overview]
Message-ID: <655D5DBB48F04F719130122440CDA29B@us.oracle.com> (raw)
In-Reply-To: <AANLkTincjezi9PLVNNxi7CFrQ+zO3cUFqAc_MPg104hM@mail.gmail.com>
> And, why are you not pissed off by "emacs --unibyte", for example?
I haven't seen it, and I don't know anything about it. If I got such a warning
each time I fired up Emacs, and if it in fact warned about no danger at all
(dunno whether it does), then I'd no doubt respond similarly about that.
My point is simply that we should warn only about impending danger. Deprecation
is not such a case (in general).
> > Why should they have to?
>
> Why should they not? By your reasoning, we should deprecate things,
> but *never* remove them,
What makes you say that? If we deprecate something then of course we should
remove it at some point. Users should not have to deactivate the warning
message - they should never see it in the first place; it makes no sense.
My objection here is to the warning, not to the deprecation or to the removal of
support for the feature.
(I also object to this particular deprecation, but that is a different issue.
And if this feature is to be deprecated then of course I am in favor of its
later being desupported - that's the point of deprecation.)
> because, why should we force users to change anything?
How do you justify that generalization? I objected to _warning_ users simply
because you are deprecating `_emacs'. You don't seem to get it.
> Well, if they are really that interested in keeping _emacs,
> they can stay with Emacs 23.
Again, off-topic. My complaint here is about the warning.
> > Why issue a _warning_ for this? As long as a user's
> > `_emacs' is found and used (traditional behavior) there
> > is nothing to warn about.
>
> We're warning them that in a not-so-distant future they will find
> their _emacs no longer working.
That's not something to warn about. There is no danger. Inform them, yes,
good. Put a deprecation notice in the manual where we talk about `_emacs'.
That's typically how deprecation is done.
A user should not see warning messages about things that are being deprecated -
unless one of the deprecations leads to some danger.
> > And if a user's `_emacs' is no longer sought and found
> > (i.e. ignored, in the future) then the warning
> > obviously does no good.
>
> I fail to understand your reasoning here, sorry.
When (after desupport) Emacs no longer looks for `_emacs', it will not be found.
Emacs will then no longer issue the warning, presumably.
(Or will you scour the user's hard drive for a `_emacs' file just so you can
warn about it not having been used?)
> > Since when does the mere act of deprecation call for a
> > _warning_? A warning is in order only if a particular
> > deprecation means there is some danger to warn about.
>
> You have already lectured us on your interpretation for the word
> "warning". I still disagree.
Google "warning". Enjoy.
Hey, but the way things are going, at some point you might well be right:
"warning" will not mean anything more than "informing". We're not there yet,
thank goodness.
> Are you really unable to talk about these matters without
> being patronizing?
ad hominem, ad hominem. Sticks and stones...
It's not about you, Juanma - and it's not about me. It's about the
pseudo-warning message, regardless of who is behind that initiative.
The message is not warning about anything. It's simply telling a user that
`_emacs' is deprecated. That's not a warning. There is no danger.
We don't need to tell users this at Emacs startup - it's not a big deal that
`_emacs' is being deprecated. Users are often frightened by "**WARNING**" - and
that's part of its effect. But there is no call for frightening users here.
next prev parent reply other threads:[~2011-03-23 0:58 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 [this message]
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
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=655D5DBB48F04F719130122440CDA29B@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 \
/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).