From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.bugs Subject: bug#8900: 24.0.50; please index mentioned coding systems in Emacs manual Date: Fri, 1 Jul 2011 14:00:01 -0700 Message-ID: References: <246694EE605F4CE391A4FB9416853D98@us.oracle.com> <83pqltriq9.fsf@gnu.org> <9BB5F2A7090B4F2585512C563D1717B3@us.oracle.com> <83liwhrdc8.fsf@gnu.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 1309554094 23073 80.91.229.12 (1 Jul 2011 21:01:34 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 1 Jul 2011 21:01:34 +0000 (UTC) Cc: larsi@gnus.org, 8900@debbugs.gnu.org To: "'Eli Zaretskii'" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Jul 01 23:01:29 2011 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1Qckq9-0007wO-EZ for geb-bug-gnu-emacs@m.gmane.org; Fri, 01 Jul 2011 23:01:29 +0200 Original-Received: from localhost ([::1]:40505 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qckq6-0001IX-8Y for geb-bug-gnu-emacs@m.gmane.org; Fri, 01 Jul 2011 17:01:26 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:38041) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qckpk-0001Ht-Nf for bug-gnu-emacs@gnu.org; Fri, 01 Jul 2011 17:01:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Qckpj-0008F9-5q for bug-gnu-emacs@gnu.org; Fri, 01 Jul 2011 17:01:04 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:59327) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qckpi-0008F5-SL for bug-gnu-emacs@gnu.org; Fri, 01 Jul 2011 17:01:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1Qckpi-0003gv-Ai; Fri, 01 Jul 2011 17:01:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: "Drew Adams" Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 01 Jul 2011 21:01:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 8900 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: fixed Original-Received: via spool by 8900-submit@debbugs.gnu.org id=B8900.130955402314140 (code B ref 8900); Fri, 01 Jul 2011 21:01:02 +0000 Original-Received: (at 8900) by debbugs.gnu.org; 1 Jul 2011 21:00:23 +0000 Original-Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Qckp4-0003g1-UZ for submit@debbugs.gnu.org; Fri, 01 Jul 2011 17:00:23 -0400 Original-Received: from acsinet11.oracle.com ([141.146.126.233]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Qckp1-0003fm-Ba for 8900@debbugs.gnu.org; Fri, 01 Jul 2011 17:00:20 -0400 Original-Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by acsinet11.oracle.com (Switch-3.4.4/Switch-3.4.2) with ESMTP id p61L0BXZ007957 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 1 Jul 2011 21:00:13 GMT Original-Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p61L0AG0027606 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 1 Jul 2011 21:00:11 GMT Original-Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p61L05fd017894; Fri, 1 Jul 2011 16:00:05 -0500 Original-Received: from dradamslap1 (/10.159.59.183) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 01 Jul 2011 14:00:04 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <83liwhrdc8.fsf@gnu.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 Thread-Index: Acw4J/aoIORbtLBZQNy85RGA5+v2sQAA72pQ X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090208.4E0E355D.00CD:SCFMA922111,ss=1,re=-4.000,fgs=0 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Fri, 01 Jul 2011 17:01:02 -0400 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:47720 Archived-At: > > Doesn't matter that we don't have detailed doc about these. > > Certainly doesn't matter that we don't have detailed doc > > about *each* coding system. > > Well, in that case, we will have to disagree. You need detailed doc about *each* coding system before you will index *any* of them? With that logic we should remove all entries from our `Variable', `Command', and `Key' indexes, since we certainly do not provide documentation - let alone "detailed documentation" - about all of them. > Having index entries about something that isn't described > is a Bad Thing. "Described" is vague here, so it's hard to judge. But you clarified earlier that only "detailed documentation" counts for you. We have similar index entries in the manuals. Looking only at the first few entries of the `Variable' index, check `blink-cursor-alist' and `auto-coding-*', for instance. There is no "detailed documentation" describing these variables. There is only a general, cursory mention of what they are for. And these are not outliers/alone in this respect. That is not a bug. We still want to index these variables, IMO. Not because we necessarily provide their "detailed documentation" in this manual (we do _not_), but because: a. we say something about them that could be useful to a user (otherwise we wouldn't mention them!), and b. we think a user might want to look them up. Those, not simply the degree of detail provided, are proper, user-oriented criteria for indexing. (Of course, if such a variable also had a more complete, detailed documentation elsewhere in the manual, then that location would likely be indexed - either in addition to or instead of the current location, depending on the context and the specific content.) I think those two criteria apply to the coding-system entries I submitted this bug about. You can disagree about that. But I would hope that you would agree about such criteria, whether or not you agree that they are satisfied in these particular cases. > > The fact is that the manual provides some information about > > these particular coding systems. They should be indexed so > > users can easily find that information. > > But there's no information to find. Yes there is. About the same degree of information as for our "descriptions" of variables `blink-cursor-alist' and `auto-coding-alist' - more, in fact. We say what the undecided-* coding systems do wrt end-of-line conversion, and we mention their aliases. > > An index does not refer only to "detailed documentation" > > about terms. It refers to terms that we think a user is > > likely to look for in the book. It is often the case that > > a term is indexed that is only mentioned in the book. > > What is important is whether a user might want to look it > > up, not how much the book goes into detail about it. > > Not in my book. Whatever. I do indexing for a living. But it's `your book'.