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: bug#10385: e binding in info-mode Date: Sat, 7 Jan 2012 14:15:45 -0800 Message-ID: <76BD385B7317495CAE8E5EBFE545A1BB@us.oracle.com> References: <201112272237.pBRMbo8C022896@freefriends.org><62fwftxnbz.fsf@fencepost.gnu.org><83fwfsoluz.fsf@gnu.org> <871urckv7k.fsf@mail.jurta.org><962D35497CE84D16B1B5F7AA509BFB59@us.oracle.com> <878vljchjo.fsf@mail.jurta.org> 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 1325974568 8538 80.91.229.12 (7 Jan 2012 22:16:08 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 7 Jan 2012 22:16:08 +0000 (UTC) Cc: 'Eli Zaretskii' , rms@gnu.org, emacs-devel@gnu.org To: "'Juri Linkov'" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jan 07 23:16:03 2012 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1RjeYU-0003Lk-T7 for ged-emacs-devel@m.gmane.org; Sat, 07 Jan 2012 23:16:03 +0100 Original-Received: from localhost ([::1]:56311 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RjeYU-0002cO-DO for ged-emacs-devel@m.gmane.org; Sat, 07 Jan 2012 17:16:02 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:49541) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RjeYR-0002Vo-AO for emacs-devel@gnu.org; Sat, 07 Jan 2012 17:16:00 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RjeYQ-0000Cz-2u for emacs-devel@gnu.org; Sat, 07 Jan 2012 17:15:59 -0500 Original-Received: from acsinet15.oracle.com ([141.146.126.227]:20879) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RjeYO-0000CB-24; Sat, 07 Jan 2012 17:15:56 -0500 Original-Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q07MFr8C018652 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 7 Jan 2012 22:15:54 GMT Original-Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q07MFqwH025196 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 7 Jan 2012 22:15:52 GMT Original-Received: from abhmt102.oracle.com (abhmt102.oracle.com [141.146.116.54]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q07MFqXQ014535; Sat, 7 Jan 2012 16:15:52 -0600 Original-Received: from dradamslap1 (/10.159.36.141) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 07 Jan 2012 14:15:51 -0800 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <878vljchjo.fsf@mail.jurta.org> thread-index: AczNhjCBMUGiSVLhQIW1/Co4zo5i2AAAVZGg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: ucsinet21.oracle.com [156.151.31.93] X-CT-RefId: str=0001.0A090204.4F08C41A.004D,ss=1,re=0.000,fgs=0 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 1) X-Received-From: 141.146.126.227 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:147462 Archived-At: > >> There is more trouble when this obsolete feature > > > > Since when is it obsolete? > > Since its inception. Info-edit was never documented in info.texi. > (And perhaps references to `Info-edit-map' should be removed > from elisp.texi) That a feature is not documented everywhere, or is poor or misguided, does not mean that it is obsolete. It is certainly not the case that a command that has been bound to a key (especially for decades) can be said to be undocumented or invisible/unknown to users. Let alone considered obsolete. Think how many commands and key bindings are not documented in any manual. They are certainly not all - or even any of them - "obsolete" since their inception. Emacs documentation is not limited to manuals, and user awareness of features is not even limited to any form of documentation. We provide source code, and that is the foundation of user communication. Typically, for a feature or a product to be considered obsolete (officially), it must first be officially deprecated. And typically there is a period of time between deprecation and obsolescence - typically a relatively major release or more. Typically, an obsolete feature is no longer supported, and a deprecated feature is still supported. For example, it might be decided to announce the deprecation of this option in 24.1, and then make it obsolete in 24.2 (since Emacs point releases are relatively major). Given such a decision, it would change from a defcustom to a defvar, or even be eliminated altogether, in 24.2, depending on what was intended wrt desupport (as an option or even as a variable). > > Why does it hurt for this to be a defcustom? > > Think about a novice looking at the available options > in the Customization group `info'. It would be a disservice > to teach them that editing Info nodes is a good idea. The existence of a user option is not the same thing as suggesting that changing its value is necessarily a good idea. We have lots of user options that it might not be a good idea for a novice, in particular, to customize. We provide plenty of rope for users to hang themselves, often even using only Customize.