Re: Info-scroll-prefer-subnodes default in Emacs.

[Luc Teirlinck]

Richard Stallman wrote:

   Does just setting Info-scroll-prefer-subnodes to nil give entirely the
   same behavior as in stand-alone info?

Yes it does.  

   If so, let's change that default.

Should I change the default and write a NEWS entry?  I guess we also
need NEWS entries for kill-whole-line, vis-mode, the new behavior of R
and friends in dired when applied to . and .. (assuming a final
decision was made on that issue, this was not completely clear) and
for Info-hide-note-references which never got mentioned in the NEWS.
I could write NEWS entries for kill-whole-line and vis-mode and, if
desired, for the two other issues.

There is actually one problem, which occurs in indices.  This problem
occurs both in the Emacs and the stand-alone version.  Actually index
menus are "weird" and cause a variety of problems which I will
describe (at least those I actually know of) in this message and the
next.

In emacs Info or stand-alone info do g (emacs)Key Index RETURN.

Now, in Emacs with Info-scroll-prefer-subnodes set to t, SPC
immediately carries us to (emacs)Shell Commands in Dired, the node
referenced by the first Index entry.  Not very useful (at least in my
opinion), but consistent.

With Info-scroll-prefer-subnodes set to nil or in the stand-alone
Info, we first scroll through the index and then go to 
(emacs)Shell Commands in Dired.  It would be more consistent with the
"browse through everything consecutively as if it were one single
document" philosophy if we went to the next node, (emacs)Option Index
instead.

There are related problems.  In Emacs Info, `]' and `[' behave as
usual in Indices.  In the stand-alone version, they do not.  (Just try
to "browse" through the various Emacs manual indices using `]' and `['
in the stand-alone Info.)

There is no easy solution for the problems described in the preceding
two paragraphs and they all have the same cause.

It would be easy to change the behavior of Emacs Info with
Info-scroll-prefer-subnodes set to nil to move through the consecutive
indices in the logical way by borrowing code from the Emacs versions
of `]' and '['.  I would guess that it would not be excessively
difficult to change all involved stand-alone behavior by adopting the
"algorithm" used by Emacs `]' and `[' to determine whether we are in
an index or not.  The problem is that the method used by `[' and `]''
is not a very reliable "algorithm" at all.  To Emacs `]' and `[' we
are in an index if and only if the node name contains the word
"index".  There are plenty of legitimate reasons for a non-index node
name to contain the name "index".  For instance, 
(texinfo)Index Entries is an actual example.  Fortunately this node
does not contain a menu, or Emacs `[' and ']' could have behaved
extremely confusingly in that neighborhood.  A reliable functioning of
Emacs `[' and ']' would require the convention that a non-index node
with a menu should *not* have the word "index" in its name.  This
convention seems to strict.

I believe all the above problems could be easily fixed once one could
answer the following question:

How do we determine reliably whether or not a node is an Index?

I do not believe that the method used by Emacs `[' and `]':
if and only if the node name contains the word "index" is reliable
enough by any means.

Sincerely,

Luc.