Re: info

[Luc Teirlinck]

Richard Stallman wrote:


          In this case, it would be good for RET to get an error.
          Probably it should take a single menu item to consist
          of the * line followed by all successive indented lines,
          including blank lines when further indented lines follow
          but excluding blank lines that would be at the end of the
          menu item.

       Problems occur in situations like:

       * Sample .emacs File::

        --- Indices ---

       * Concept Index::

   I see the problem, but don't worry about it too much.
   It doesn't have to be perfect, just better.

   It would be better to make occasional rare mistakes like this
   than to fail frequently on multi-line menu items.

Yes, but I have found worse examples since and the problem cases do
not seem to be that rare at all.  Two examples among the many I found:

Example 1:

* Menu:

* Interactive Customization::
* Permanent Customization::
* Hooks::
* Styles::
* Advanced Customizations::

   ---------- Footnotes ----------

   (1) Available in Emacs 20 and later, and XEmacs 19.15 and later.

   (2) Obviously, you use the key binding interactively, and the
function call programmatically!

   (3) There is however a variable `c-strict-syntax-p' that, when set
to non-`nil', will cause an error to be signaled in that case.  It's
now considered obsolete since it doesn't work well with some of the
alignment functions that now returns `nil' instead of zero to be more
usable in lists.  You should therefore leave `c-strict-syntax-p' set
to
`nil'.

   (4) You can try this interactively in a C buffer by typing the text
that appears in italics.

My comments:

The described algorithm would still go "* Advanced Customizations::"
at the end of the first line of footnote (2) and, even then, we are
lucky that footnote (2) is multi-line.  Worse could have happened.

Example 2:

* Other Commands::

   See also *Note Text Filling and Line Breaking::, for commands concerning
that bit.

My comments:

With point after "concerning", the algorithm would still go to
"* Other Commands::", even though there is a cross-reference in between.

As I said such examples are not rare.

I see at least three solutions that would be better than the algorithm
you propose:

1.  Take over the stand-alone behavior, maybe with an improved error
    message.

Advantage:  Never produces confusion, if the error message is
sufficiently clear.

2.  The second proposal I made, namely do whatever mouse-2 would,
    otherwise whatever "m RETURN" would do by default, otherwise
    nothing.

Advantage: Always does the obvious thing if there is one.
Disadvantage: can look very unnatural, but only in situations where
pressing RETURN is very unnatural to begin with, and is completely
consistent and predictable.

3.  Use Kai's algorithm.

The reason why I believe that 2. is relatively better than the
solution you propose, is that a surprised user could at least easily
figure out what the behavior is, using C-h k or by experimentation.
That is not the case with the solution you propose. Take example 1.
The user presses RETURN in the described spot (out of curiosity, I can
not see any other reason) and sees that (s)he winds up in
* Advanced Customizations::  Now the user believes that when (s)he
presses RETURN in a footnote (s)he will always go to the last menu
item.  True for 2., but with the algorithm you propose, (s)he is in
for some further surprises.

In as far as 3. is concerned, I have not found any example yet where
Kai's algorithm goes obviously wrong.  Kai's algorithm obviously
malfunctions for descriptions containing blank lines.  But such cases
seem to be more rare than the instances in which the algorithm you
describe malfunctions.  (Actually, I have not even found a concrete
example yet, although I am sure there must be some somewhere.)
However, anything we implement should work for all info files.  That
includes, for instance, files not originally written in texinfo but
automatically generated from, say, SGML files.  I have no experience
whatsoever with these and do not know whether they could have weird
indentation and, hence, lead to major malfunctioning of any
indentation based algorithm.

Of the three above solutions, 1. seems the safest, even though I agree
it is not ideal.  But there does quite simply not seem to be an ideal
solution.

Sincerely,

Luc.