From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.devel Subject: RE: Deprecate _emacs on Windows Date: Wed, 23 Mar 2011 07:09:48 -0700 Message-ID: <9BB0B675F0A64762BC3FDBD9A9B02C1A@us.oracle.com> References: <0B6A6EC5FD8F46D697F914FB2F6D4304@us.oracle.com><655D5DBB48F04F719130122440CDA29B@us.oracle.com> <87pqpi8qui.fsf@uwakimon.sk.tsukuba.ac.jp> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1300889456 9482 80.91.229.12 (23 Mar 2011 14:10:56 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 23 Mar 2011 14:10:56 +0000 (UTC) Cc: 'Juanma Barranquero' , 'Lennart Borgman' , 'Stefan Monnier' , 'Emacs developers' To: "'Stephen J. Turnbull'" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Mar 23 15:10:50 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Q2Olr-0006fV-0B for ged-emacs-devel@m.gmane.org; Wed, 23 Mar 2011 15:10:50 +0100 Original-Received: from localhost ([127.0.0.1]:53978 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Q2Olo-0008MB-Jk for ged-emacs-devel@m.gmane.org; Wed, 23 Mar 2011 10:10:44 -0400 Original-Received: from [140.186.70.92] (port=56974 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Q2Ol7-000865-MC for emacs-devel@gnu.org; Wed, 23 Mar 2011 10:10:03 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Q2Ol6-00040E-2S for emacs-devel@gnu.org; Wed, 23 Mar 2011 10:10:01 -0400 Original-Received: from rcsinet10.oracle.com ([148.87.113.121]:41705) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Q2Ol5-0003ze-TL for emacs-devel@gnu.org; Wed, 23 Mar 2011 10:10:00 -0400 Original-Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id p2NE9u5s014781 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 23 Mar 2011 14:09:57 GMT Original-Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id p2NE9shv001199 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 23 Mar 2011 14:09:55 GMT Original-Received: from abhmt017.oracle.com (abhmt017.oracle.com [141.146.116.26]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p2NE9rd5018593; Wed, 23 Mar 2011 09:09:54 -0500 Original-Received: from dradamslap1 (/10.159.58.141) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 23 Mar 2011 07:09:53 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <87pqpi8qui.fsf@uwakimon.sk.tsukuba.ac.jp> Thread-Index: AcvpCJ6YS0z4AB8GQWubboDigcOP4wAV47UQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 X-Source-IP: acsmt358.oracle.com [141.146.40.158] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090204.4D89FF34.0068,ss=1,fgs=0 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 148.87.113.121 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:137569 Archived-At: > > 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.