From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Luc Teirlinck Newsgroups: gmane.emacs.devel Subject: Re: Info enhancements Date: Tue, 9 Dec 2003 21:29:28 -0600 (CST) Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <200312100329.hBA3TSo24075@raven.dms.auburn.edu> References: <878ylrbbk4.fsf@mail.jurta.org> <200312051827.hB5IRfk17741@f7.net> <87isku20s6.fsf@mail.jurta.org> <200312071844.hB7Iiun11495@raven.dms.auburn.edu> NNTP-Posting-Host: deer.gmane.org X-Trace: sea.gmane.org 1071027563 20595 80.91.224.253 (10 Dec 2003 03:39:23 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 10 Dec 2003 03:39:23 +0000 (UTC) Cc: juri@jurta.org, bob@rattlesnake.com, karl@freefriends.org, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Wed Dec 10 04:39:15 2003 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1ATvBz-0002i1-00 for ; Wed, 10 Dec 2003 04:39:15 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1ATvBy-000763-00 for ; Wed, 10 Dec 2003 04:39:15 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.24) id 1ATw8R-0004Mq-LE for emacs-devel@quimby.gnus.org; Tue, 09 Dec 2003 23:39:39 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.24) id 1ATw7Q-0004Hi-SS for emacs-devel@gnu.org; Tue, 09 Dec 2003 23:38:36 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1ATw6s-0003xn-Vt for emacs-devel@gnu.org; Tue, 09 Dec 2003 23:38:34 -0500 Original-Received: from [131.204.53.104] (helo=manatee.dms.auburn.edu) by monty-python.gnu.org with esmtp (Exim 4.24) id 1ATw6N-0003sU-CL; Tue, 09 Dec 2003 23:37:31 -0500 Original-Received: from raven.dms.auburn.edu (raven.dms.auburn.edu [131.204.53.29]) by manatee.dms.auburn.edu (8.12.10/8.12.10) with ESMTP id hBA3aIKk013600; Tue, 9 Dec 2003 21:36:18 -0600 (CST) Original-Received: (from teirllm@localhost) by raven.dms.auburn.edu (8.11.6+Sun/8.11.6) id hBA3TSo24075; Tue, 9 Dec 2003 21:29:28 -0600 (CST) X-Authentication-Warning: raven.dms.auburn.edu: teirllm set sender to teirllm@dms.auburn.edu using -f Original-To: rms@gnu.org In-reply-to: (message from Richard Stallman on Mon, 08 Dec 2003 14:28:18 -0500) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.2 Precedence: list List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:18602 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:18602 Richard Stallman wrote: There may be difficulties in splitting Window frame parameters. Splitting Coding Conventions is possible if someone can think of a good subtopic that a large fraction fit into. I agreed to start splitting nodes. However, I actually started trying to do so and very soon I started doubting whether this was, right now, the best thing to do. Even though there is no specific deadline, we are preparing to release a new printed version of the Elisp manual. Splitting nodes or even moving many items between nodes requires a lot of work. Splitting the node itself is not the worst part, the real work is looking up all references to the old node in all manuals included with the Emacs distribution and deciding to which of the two new nodes they should refer. Often, we will need to reference both new nodes. (Moving remq is OK, because there appears to be little danger with that one.) We need to do this anew each time we split a node and if we decide that even `Creating Strings' with its 204 lines is too big, then there are _many_ nodes to split. On the other hand, we already decided that splitting the second largest node in the manual, `Window frame parameters', 338 lines, is undesirable. If the only reason to split nodes is so that the reader will have no difficulties following references, then I believe that it is substantially less work to systematically go through all references in the elisp manual and check which ones could use @anchor's. I did this for `Non-ASCII Characters' and it is less work than one might expect. The @anchor solution works well for both info and for the printed manual. Since Juri's proposed feature only works for info and does not adjust page numbers in the printed manual, it is not a real alternative. I propose, at least for this edition of the manual, since there appears to be still so much work to do, to just try to put in @anchor's in all places where needed and not to split nodes based solely on their length. Sincerely, Luc.