emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Info enhancements


From: Luc Teirlinck
Subject: Re: Info enhancements
Date: Tue, 9 Dec 2003 21:29:28 -0600 (CST)

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.
 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]