Path: utzoo!telly!ddsw1!lll-winken!brutus.cs.uiuc.edu!gem.mps.ohio-state.edu!tut.cis.ohio-state.edu!UHCCUX.UHCC.HAWAII.EDU!stampe
From: stampe@UHCCUX.UHCC.HAWAII.EDU (David Stampe)
Newsgroups: gnu.emacs.bug
Subject: "Next" in info headers pointing to submenu item 1 rather than next
Message-ID: <8911212227.AA20919@uhccux.uhcc.Hawaii.Edu>
Date: 21 Nov 89 22:27:15 GMT
Sender: daemon@tut.cis.ohio-state.edu
Distribution: gnu
Organization: GNUs Not Usenet
Lines: 81

In a number of info files, including some generated from texinfo source,
the "Next" pointer in headers sometimes points not to the next node at
the same level (i.e. the next sibling node), but to the first node in
the submenu.  Here's one of many examples, from the info file for GNU tar:

(From the Top menu:)
* Options::		Options that change the way `tar' behaves.
* FullDumps::		Using `tar' to perform full dumps.

File: tar  Node: Options, Prev: Commands, Up: Top, Next: General Options
						   ^^^^^^^^^^^^^^^^^^^^^
>> THIS SHOULD SAY				   Next: FullDumps

(From the Options menu:)
* General Options::		Options that are always meaningful.

The result is that there's no way to get to FullDumps from Options except
by going back to the Top menu and doing "mFullDumps".

Probably this has been considered a "feature": having Next point to 1
rather than the actual next could be considered reasonable in a node
with no contents except a menu, but in fact, besides being confusing,
it just makes it much harder for a user to read breadth-first if he
chooses.  Pointers like this reduce info to merely a complicated "man".

If it is really felt that depth-first reading should be the default,
info could bind a key like RET to a command for linear readers:

(defun Info-go-with-the-flow ()
  "Move forward to whatever page or node logically comes next.
Specifically: If not at the end of the node, scroll forward (like SPC).
 Else, if there is a menu, go to its first item (like `1').
  Else go to the Next node, if any (like `n').
   Else go to the Up node and to its Next node."
...)

I have code for this and would be glad to submit it for consideration
for info.el.  But even this must have loop-protection built in for the
headers I'm complaining about, where Next points to 1 rather than next!

To fix those headers, for normal users who want the option to read info
files any way they please, the following needs to be done:

  1. Correct the Next pointers in texinfo source files and in
     any info files that are distributed ready-made.

  2. Maybe have Info-validate in informat.el complain about Next's
     that don't point to the next sibling node.

  3. Revise info and texinfo documents to advise against such pointers.

  4. If the new texinfo program constructs nexts automatically,
     make sure it gets them right.

If FSF is willing to apply the diffs, I'm willing to attempt 1-3.

David Stampe (stampe@uhccux.uhcc.hawaii.edu)

PS. Some thought should given to a revision of info in which node
headers do not appear in the file, but perhaps in the modeline (or in
an X window perhaps in is label); and in which menus and maybe even
crossreferences need not appear in the file, but pop up when one
wants to see them.  A menu on a given topic should be able to send the
user through any succession of next's, independently of the internal
structure (or node headers) of the files that happen to expound the
subtopics.  Menus might be thought of as different syllabuses for
perusing the same library of Great Books.

Info is one of the first hypertext systems, maybe THE first, but it
should be able to access topics and levels in texts without mutilating
the texts.  As things stand, the beginning of an info-accessible copy
of Dante's Inferno has to say something like

* Menu:
* First Circle::	Abandon hope all ye who press "m".
...
* Ninth Circle::	This node has no next.

Kidding aside, such stuff shouldn't have to appear IN the text.  Info
ought to provide menu access to any kind of files - code, data, mail,
whatever - without intruding itself into their contents.