info

info

[Luc Teirlinck]

The following may not be the biggest problem in the world, but I still
find it confusing.  I believe it is an Emacs problem, but it could be
an info problem, in which case I am posting at the wrong place.

Here is a copy of a part of my info "Top" node:

* Ada mode: (ada-mode). Emacs mode for editing Ada code.
* Autotype: (autotype). Convenient features for text that you enter frequently
                          in Emacs.
* CC Mode: (ccmode).   Emacs mode for editing C, C++, Objective-C,
                          Java, Pike, and IDL code.
* CL: (cl).			Partial Common Lisp support for Emacs Lisp.
* Calc: (calc).			Advanced desk calculator and mathematical tool.
* Dired-X: (dired-x).   Dired Extra Features.
* EUDC: (eudc).   An Emacs client for directory servers (LDAP, PH).
* Ebrowse: (ebrowse).   A C++ class browser for Emacs.
* Ediff: (ediff).       A visual interface for comparing and merging programs.
* Elisp: (elisp).	The Emacs Lisp Reference Manual.
* Emacs: (emacs).	The extensible self-documenting text editor.
* Emacs FAQ: (efaq).	Frequently Asked Questions about Emacs.
* Emacs Lisp Intro: (eintr).
		    A simple introduction to Emacs Lisp programming.
* Eshell: (eshell).     A command shell implemented in Emacs Lisp.

If point is on say: Java in the above and I click return I visit the
CL node.  If it is anywhere in:
"A simple introduction to Emacs Lisp programming",
I visit the Eshell node.

Would it not be more logical to look at previous (rather than
following) lines for which node to visit, since that is usually the
node the text we are looking at refers to?  (Unless there are no
previous nodes, in which case the "following node" behavior is indeed 
convenient.)

Sincerely,

Luc.

Re: info

[Luc Teirlinck]

Let me make a concrete proposal:

Redefine RETURN in Info-mode to be just a shortcut for "m RETURN".  In
other words, the only difference between RETURN and m would be that if
m has an interactive default, then RETURN accepts it without querying.
This would leave the behavior of RETURN unchanged in all situations
where it currently is useful, intuitive or non-confusing.  It would
also provide for the intuitive selection in the situations I referred
to in my previous posting.  If it is impossible to figure out which
node the user really wants, then, rather than info making a completely
wild guess, as it currently does, the user would be alerted to that
fact with

Menu item:

appearing in the echo area.

Sincerely,

Luc.

Re: info

[Eli Zaretskii]

On Tue, 28 Jan 2003, Luc Teirlinck wrote:

> Redefine RETURN in Info-mode to be just a shortcut for "m RETURN".

That's not good: RET also follows a cross-reference near point, not only 
menu items.  So it must first find out what is ``the thing'' near point 
that it should follow, and then do it.

> If it is impossible to figure out which
> node the user really wants, then, rather than info making a completely
> wild guess, as it currently does, the user would be alerted to that
> fact with
> 
> Menu item:
> 
> appearing in the echo area.

I'm not sure I like it: what RET does currently in Info is similar to 
many other programs which support links or references of some kind: if 
there's no link anywhere in sight, they do nothing, no questions asked.
Users generally know that if RET didn't have any effect, point is not on 
a link.  What you suggest deviates significantly from that behavior, and 
I seriously wonder whether the downsides of the deviation are justified 
by whatever gains you think we'll have.

Re: info

[Luc Teirlinck]

Eli Zaretskii wrote:

   That's not good: RET also follows a cross-reference near point, not only 
   menu items.  So it must first find out what is ``the thing'' near point 
   that it should follow, and then do it.

You are right here.  I forgot about xrefs and the like.  I retract my
original suggestion.

However, you seem to vastly underestimate the differences between
stand-alone behavior and Emacs behavior.

   I'm not sure I like it: what RET does currently in Info is similar to 
   many other programs which support links or references of some kind: if 
   there's no link anywhere in sight, they do nothing, no questions asked.
   Users generally know that if RET didn't have any effect, point is not on 
   a link.  What you suggest deviates significantly from that behavior, and 
   I seriously wonder whether the downsides of the deviation are justified 
   by whatever gains you think we'll have.

That may be what RETURN does in stand-alone info.  In the Emacs version
however, RETURN currently always tries to do something, whether there
is something obvious to do or not.  The consequences can be extremely
confusing.

   I don't remember all the intricacies of this, but I do remember that it 
   is not always easy to decide what menu item to select.

But, that is exactly the problem.  The Emacs version makes decisions
in cases where trying to make a decision is hopeless, resulting in
wild and unpredictable behavior.  I hope newbies learn about the `l'
key fast, or they are not going to have fun with RETURN.

   IMHO we should not change what RET does if it cannot find any link
   nearby.

What you seem to be saying is that it should not be changed from its
stand-alone behavior.  That means a radical change for the Emacs
version.

   I like the behavior of the stand-alone Info better than what Emacs
   does now and better than what you propose.  (But then I'm not
   objective about this: I worked on these aspects of the stand-alone
   reader.)

I guess we all like it better than what Emacs does now.  Also, of
course you do not like what I proposed, even I do not like it anymore.
The only concrete proposal I made was silly, I completely overlooked
something.  (Sorry about that.)

Changing Emacs behavior to the stand-alone behavior you describe would
be acceptable to me.  It would also be helpful to users using both if
they were made more compatible.  Note however, that in as far as the
Emacs version is concerned, that constitutes a change.

A possible alternative would be to make RETURN do the same thing as
mouse-2 if mouse-2 does something (includes xrefs), otherwise the same
as m RETURN if that does something (by default), otherwise nothing.
If there is an obvious choice, that chooses it.  Whenever there is no
obvious choice, only users familiar with the way m chooses defaults in
the given situation would be tempted to use it anyway.  Again however,
the stand-alone behavior you describe sounds perfectly acceptable.

One last example of actual behavior in the Emacs version.  Do:
C-h i m emacs m killing.  We see:

* Menu:

* Deletion::            Commands for deleting small amounts of text
  and
                          blank areas.
* Killing by Lines::    How to kill entire lines of text at one time.
* Other Kill Commands:: Commands to kill large regions of text and
                          syntactic units such as words and sentences.


Place point on syntactic, in the last line of the quote.  Which node do
you expect to go to if you press RETURN and which one do you actually
go to (in the Emacs version).

I believe the present Emacs situation definitely needs a change.

Sincerely,

Luc.

Re: info

[Eli Zaretskii]

On Wed, 29 Jan 2003, Luc Teirlinck wrote:

> What you seem to be saying is that it should not be changed from its
> stand-alone behavior.

Yes.

> That means a radical change for the Emacs version.

Probably.

> Changing Emacs behavior to the stand-alone behavior you describe would
> be acceptable to me.  It would also be helpful to users using both if
> they were made more compatible.

I agree.  I doubt if they could ever behave identically, but I think we 
should make them more similar.

> * Menu:
> 
> * Deletion::            Commands for deleting small amounts of text
>   and
>                           blank areas.
> * Killing by Lines::    How to kill entire lines of text at one time.
> * Other Kill Commands:: Commands to kill large regions of text and
>                           syntactic units such as words and sentences.
> 
> 
> Place point on syntactic, in the last line of the quote.  Which node do
> you expect to go to if you press RETURN

I expect it to go nowhere, as the stand-lone reader does.

Re: info

[Richard Stallman]

    Redefine RETURN in Info-mode to be just a shortcut for "m RETURN".  In
    other words, the only difference between RETURN and m would be that if
    m has an interactive default, then RETURN accepts it without querying.

It used to be that typing RET on the Next, Previous and Up pointers
worked too, but that is no longer possible because those pointers
are now in the header line.  So the only things RET can do now
are m and f.

If you're suggesting that we turn of the f functionality, I think that
is a bad idea.  But if you're suggesting that we make RET get an error
when it is not in the menu or on a cross-reference, I think that is a
good idea.  Please write the code for that if you would like to.

    If it is impossible to figure out which
    node the user really wants, then, rather than info making a completely
    wild guess, as it currently does, the user would be alerted to that
    fact with
    
    Menu item:
    
    appearing in the echo area.

That is definitely a bad idea, as Eli explained.

Re: info

[Eli Zaretskii]

> Date: Tue, 28 Jan 2003 19:33:18 -0600 (CST)
> From: Luc Teirlinck <teirllm@dms.auburn.edu>
> 
> * CC Mode: (ccmode).   Emacs mode for editing C, C++, Objective-C,
>                           Java, Pike, and IDL code.
> * CL: (cl).			Partial Common Lisp support for Emacs Lisp.
[...]
> If point is on say: Java in the above and I click return I visit the
> CL node.

FWIW, the stand-alone Info reader doesn't move point in such cases and
either says nothing or prints "No cross references in this node."  It
only follows a menu item if point is on the same line as the leading
"* " sequence after a newline, a sequence which starts every menu
item.

> Would it not be more logical to look at previous (rather than
> following) lines for which node to visit, since that is usually the
> node the text we are looking at refers to?

I like the behavior of the stand-alone Info better than what Emacs
does now and better than what you propose.  (But then I'm not
objective about this: I worked on these aspects of the stand-alone
reader.)

Please also keep in mind that some menus have free text in between
menu items, which doesn't belong to any menu item at all.  Here's an
example from the Emacs manual:

    * Acknowledgments::     Major contributors to GNU Emacs.

    Indexes (nodes containing large menus)
    * Key Index::           An item for each standard Emacs key sequence.

Which menu item would you like Info to select if point is on
"Indexes", and how should Info tell this case from the one that
started this thread?

Again, I'm not arguing that the current behavior is the best we could
do, or that it should not be changed under any circumstances.  I'm
just trying to point out potential pitfalls, and given that, get to
some agreement about what we would like to see in each situation.

Re: info

[Luc Teirlinck]

Eli Zaretskii wrote:

   Please also keep in mind that some menus have free text in between
   menu items, which doesn't belong to any menu item at all.  Here's an
   example from the Emacs manual:

       * Acknowledgments::     Major contributors to GNU Emacs.

       Indexes (nodes containing large menus)
       * Key Index::           An item for each standard Emacs key sequence.

   Which menu item would you like Info to select if point is on
   "Indexes", and how should Info tell this case from the one that
   started this thread?

Sorry, I forgot to answer this question.  The default chosen by m is
`Acknowledgments'.  This is arbitrary but predictable.  Everything
between two leading *'s is the previous *'s territory.  Again if there
is an obvious choice it is chosen.  If there is no obvious choice, we
can not be logical, only predictable.  Current Emacs behavior is
basically unpredictable and makes irrational choices even if there is
a completely obvious choice.  Users will not press RETURN in the
situation you describe unless they understand the way choices are
made.  In the situations I described, however, they would press RETURN
because the desired node seems completely obvious.

Sincerely,

Luc.

Re: info

[Luc Teirlinck]

>From my previous message:

   Everything between two leading *'s is the previous *'s territory.

Note that this gets taken very literally.  Extreme example from
ccmode:

* Variable Index::

 --- The Detailed Node Listing ---

New Indentation Engine

* Syntactic Analysis::
* Indentation Calculation::

With point right before the Syntactic Analysis line, the default for m
is still Variable Index.  I do not see how to both select the intended
nodes in the situations I described and avoid this behavior.  The
question is, as I explained in my previous message, whether this
behavior is really bad, because it does the obvious right thing
whenever there is such a thing and is easily predictable and
completely consistent in other cases.  It is not "natural", but it is
not "natural" to press RETURN in those places to begin with, unless
one knows what the result is going to be.

The only obvious alternative I see is Eli's suggestion to adopt the
current stand-alone behavior.  Again, this alternative is perfectly
acceptable to me, since my main objection was confusion rather than
inconvenience.

Sincerely,

Luc.

Re: info

[Eli Zaretskii]

On Wed, 29 Jan 2003, Luc Teirlinck wrote:

>        * Acknowledgments::     Major contributors to GNU Emacs.
> 
>        Indexes (nodes containing large menus)
>        * Key Index::           An item for each standard Emacs key sequence.
> 
>    Which menu item would you like Info to select if point is on
>    "Indexes", and how should Info tell this case from the one that
>    started this thread?
> 
> Sorry, I forgot to answer this question.  The default chosen by m is
> `Acknowledgments'.  This is arbitrary but predictable.  Everything
> between two leading *'s is the previous *'s territory.

I believe this arebitrary predictability is not very useful, except in 
those cases where the text between the two *'s is short.  As other 
examples in this thread show, sometimes this approach is simply wrong.

Re: info

[Kai Großjohann]

Eli Zaretskii <eliz@is.elta.co.il> writes:

> I believe this arebitrary predictability is not very useful, except in 
> those cases where the text between the two *'s is short.  As other 
> examples in this thread show, sometimes this approach is simply wrong.

First of all, if point is on a menu line, then choose that menu
item.  That much we all agree on.

Further, if point is on a line starting with whitespace and
containing some non-whitespace text, this could be a continuation
line for a menu line.

Here's an algorithm:

IF point is on a menu line
THEN
    choose that menu item
ELSE
    IF point is on a line that starts with whitespace and contains
       non-whitespace characters
    THEN
        WHILE point is on a nonblank line starting with whitespace
        DO
            move up one line
        END
        IF point is on a menu line
        THEN
            choose that menu item
        FI
    FI
FI

What do people think?
-- 
Ambibibentists unite!

Re: info

[Luc Teirlinck]

One could also try to use the text properties involved (display), but
I am not sure just how reliable any of these heuristics are.
To elaborate a little bit on what I mean:

* CC Mode: (ccmode).   Emacs mode for editing C, C++, Objective-C,
                          Java, Pike, and IDL code.

Put point on the `J' in Java.  Playing around with C-b or C-f, you see
that you stay on J twice.  Do C-u C-x =

Sincerely,

Luc.

Re: info

[Luc Teirlinck]

>From my previous message:

   One could also try to use the text properties involved (display), but
   I am not sure just how reliable any of these heuristics are.

On second thought, bad idea.  Any line could start with display text
properties.

Sincerely,

Luc.

Re: info

[Eli Zaretskii]

> From: kai.grossjohann@uni-duisburg.de (Kai =?iso-8859-1?q?Gro=DFjohann?=)
> Date: Thu, 30 Jan 2003 09:39:13 +0100
> 
> First of all, if point is on a menu line, then choose that menu
> item.  That much we all agree on.

Doesn't Emacs do that now?  I thought it did.

> Further, if point is on a line starting with whitespace and
> containing some non-whitespace text, this could be a continuation
> line for a menu line.

I think this should be removed and instead Emacs should not go
anywhere in those cases.  Several examples in this thread show how
such ad-hoc algorithms can fail miserably.  Can you explain why do you
think this behavior is better than what the stand-alone reader does?

Re: info

[Kai Großjohann]

"Eli Zaretskii" <eliz@is.elta.co.il> writes:

>> From: kai.grossjohann@uni-duisburg.de (Kai =?iso-8859-1?q?Gro=DFjohann?=)
>> Date: Thu, 30 Jan 2003 09:39:13 +0100
>> 
>> First of all, if point is on a menu line, then choose that menu
>> item.  That much we all agree on.
>
> Doesn't Emacs do that now?  I thought it did.

Oh, it does.  Sorry for that misinformation.

>> Further, if point is on a line starting with whitespace and
>> containing some non-whitespace text, this could be a continuation
>> line for a menu line.
>
> I think this should be removed and instead Emacs should not go
> anywhere in those cases.  Several examples in this thread show how
> such ad-hoc algorithms can fail miserably.  Can you explain why do you
> think this behavior is better than what the stand-alone reader does?

OK, the standalone behavior is also fine.  (The error message could
be improved, perhaps, but that's a minor thing.)

I agree with the previous statement that an error is better than the
wrong target.
-- 
Ambibibentists unite!

Re: info

[Robert J. Chassell]

Today's CVS snapshot, Thu, 2003 Jan 30  22:22 UTC,
GNU Emacs 21.3.50.112 (i686-pc-linux-gnu, X toolkit)
started with

     /usr/local/bin/emacs -q --no-site-file --eval '(blink-cursor-mode 0)'

   > First of all, if point is on a menu line, then choose that menu
   > item.  That much we all agree on.

   Doesn't Emacs do that now?  I thought it did.

No, it does not -- not in the Dir file.   This is one of the problems.

In the Dir file, when point is in a description, and you press RET,
Emacs does not visit the Info file, but returns an error message that
says:

    Info-next-preorder: No more nodes

(The command that RET invokes is `Info-follow-nearest-node'.)

However, when point is at the beginning of a menu line (just before
the asterisk) or when point is within the name of the menu item, and
you press RET, then Emacs does visit the Info file.

On the other hand, within a document, whenever point is anywhere on a
menu entry line, even when it is a description, then when you press
RET, Emacs visits the appropriate node.

-- 
    Robert J. Chassell                         Rattlesnake Enterprises
    http://www.rattlesnake.com                  GnuPG Key ID: 004B4AC8
    http://www.teak.cc                                     bob@gnu.org

Re: info

[Luc Teirlinck]

Robert Chassell wrote:

   In the Dir file, when point is in a description, and you press RET,
   Emacs does not visit the Info file, but returns an error message that
   says:

       Info-next-preorder: No more nodes

It visits the Info file if you are on the actual *-line.  Otherwise a
variety of things can happen, depending on the situation.

For instance:

* Emacs Lisp Intro: (eintr).
		        A simple introduction to Emacs Lisp programming.
* Eshell: (eshell).     A command shell implemented in Emacs Lisp.

Note: (eintr) and (eshell) only became visible after yanking.
If I press RETURN on "A simple ...", I would be visiting the Eshell
file,  because I am not on the *-line.  If Emacs Lisp Intro: were
the last node, I would be getting the error message you got.

Positioning point above the `A" goes to `File: eintr'.  We see:

* Narrowing & Widening::        Restricting your and Emacs attention to
                                    a region.
* car cdr & cons::              Fundamental functions in Lisp.

RETURN on "Restricting ..." goes to "Narrowing & Widening::" 
RETURN on "a region." goes to "car cdr & cons::"

We all agree that the behavior on the *-line is correct and the
behavior on the next line wrong.  What we are discussing is what the
behavior on other lines should be.  At first it looks obvious: we want
exactly the same behavior as on the *-line in both cases since we are
on a continuation line.  (That is exactly what I originally proposed.)
But somehow things are not that straightforward, for reasons discussed
earlier in this thread.

Sincerely,

Luc.

Re: info

[Robert J. Chassell]

Today's CVS snapshot, Fri, 2003 Jan 31  12:37 UTC
GNU Emacs 21.3.50.113 (i686-pc-linux-gnu, X toolkit)
started with

     /usr/local/bin/emacs -q --no-site-file --eval '(blink-cursor-mode 0)'

I wrote:

          In the Dir file, when point is in a description, and you
          press RET, Emacs does not visit the Info file, but returns
          an error message that says:

              Info-next-preorder: No more nodes

  Luc Teirlinck <teirllm@dms.auburn.edu> responded

       It visits the Info file if you are on the actual *-line.

No, it does not do that in my dir file, but it does visit the proper
node when within a manual.  I do not know why this is.  This is with a
plain vanilla Emacs: no .emacs file, no site file.

When dir is

  /usr/local/info/dir

and point is just before the `r' of `format', in the menu line that
says:

* Texinfo: (texinfo).				The GNU documentation format.

when I press RET (Info-follow-nearest-node), I receive the error message:

    Info-next-preorder: No more nodes

However, when point is just before the `x' of `Texinfo', 
when I press RET, I visit the Texinfo manual.  

Within that manual, regardless of where point is on a *-line, RET
(Info-follow-nearest-node) sends me to the node for that line.

-- 
    Robert J. Chassell                         Rattlesnake Enterprises
    http://www.rattlesnake.com                  GnuPG Key ID: 004B4AC8
    http://www.teak.cc                                     bob@gnu.org

Re: info

[Luc Teirlinck]

Robert Chassell wrote:

   When dir is

     /usr/local/info/dir

   and point is just before the `r' of `format', in the menu line that
   says:

   * Texinfo: (texinfo).                       The GNU documentation format.

   when I press RET (Info-follow-nearest-node), I receive the error message:

       Info-next-preorder: No more nodes

I believe this must be a problem with your Dir file.

I witnessed the behavior I described with exactly the same command
line arguments you gave with CVS bootstrapped at pretty much the same
time you did.  From discussions with Kai and Richard, I get the
impression that the behavior I described is also the behavior they are
witnessing.  In the situation you describe, RETURN carries me to
texinfo, as expected.

Just in case:

[bash2.05b.0 ~ 3 3] makeinfo --version
makeinfo (GNU texinfo) 4.2

In an unrelated matter:

   /usr/local/bin/emacs -q --no-site-file --eval '(blink-cursor-mode 0)'

I guess you must be susceptible to the "blinking cursor phenomenon"
too.  It is strange how such a tiny blinking black box can have this
dramatic effect on the nervous system of a small minority of people
(it is torture), whereas it apparently leaves the vast majority of
people completely unaffected.

Sincerely,

Luc.

Re: info

[Robert J. Chassell]

Luc Teirlinck <teirllm@dms.auburn.edu> says

   I believe this must be a problem with your Dir file.

I hope so.  The problem is, my Dir file is pretty normal, constructed
by Debian testing and GNU Emacs.

You say you are using      makeinfo (GNU texinfo) 4.2

In my case

    # makeinfo --version
    makeinfo (GNU texinfo) 4.3

although I don't think the higher version is the problem.  I think the
bug is more likely a side effect of fairly normal, but not usually
considered, installation of GNU.  But I don't know for sure.



   In an unrelated matter:

      /usr/local/bin/emacs -q --no-site-file --eval '(blink-cursor-mode 0)'

   I guess you must be susceptible to the "blinking cursor phenomenon"
   too.  It is strange how such a tiny blinking black box can have this
   dramatic effect on the nervous system of a small minority of people
   (it is torture), whereas it apparently leaves the vast majority of
   people completely unaffected.

Yes.  It is strange.  But then, I know many people who like breathing
exhaust fumes from cars and sleeping with bright lights and loud
noises, even though they do not have to.

-- 
    Robert J. Chassell                         Rattlesnake Enterprises
    http://www.rattlesnake.com                  GnuPG Key ID: 004B4AC8
    http://www.teak.cc                                     bob@gnu.org

Re: info

[Richard Stallman]

    If point is on say: Java in the above and I click return I visit the
    CL node.  If it is anywhere in:
    "A simple introduction to Emacs Lisp programming",
    I visit the Eshell node.

    Would it not be more logical to look at previous (rather than
    following) lines for which node to visit, since that is usually the
    node the text we are looking at refers to?

I agree.  Would you like to change it?

Re: info

[Luc Teirlinck]

Richard Stallman wrote:

       Would it not be more logical to look at previous (rather than
       following) lines for which node to visit, since that is usually
       the node the text we are looking at refers to?

   I agree.  Would you like to change it?

(More heavily indented lines are quoted from an earlier message of
mine.)

Depends.  I can not promise anything before having done it.  I
definitely do not know how to implement my proposal, without the
"feature" I explained in a previous posting.  If we go for the other
obvious solution, take over the stand-alone behavior, then we could
just take over that code.  (Or so I guess.)

Sincerely,

Luc.

Re: info

[Luc Teirlinck]

At second thought, maybe the extreme example I gave in a previous
message (with point as described) could be confusing to users, after
all.

I am starting to lean to Eli's suggestion (adopting the stand-alone
info behavior), as that one never goes to the "wrong" node and never
produces confusion.  It would be better if RETURN actually went to the
desired node in the situations I described, but again, I do not see
how to get the "best of both worlds".

I believe that my proposal would not be very difficult to implement if
one does not mind about the example I gave (because most of the
functionality is already implemented by other functions), but once one
minds about that example I am at a total loss.  The very example I
gave shows that you can not even use indentation in the obvious way.

Sincerely,

Luc.

Re: info

[Luc Teirlinck]

>From my previous message:

   It would be better if RETURN actually went to the desired node in
   the situations I described, but again, I do not see how to get the
   "best of both worlds".

To be more explicit: not going anywhere is a lot better than going the
wrong place.  As mentioned before, I am more worried about confusion
than convenience.

Sincerely,

Luc.

Re: info

[Eli Zaretskii]

On Wed, 29 Jan 2003, Kai =?iso-8859-1?q?Gro=DFjohann?= wrote:

> But still, if RET selects the menu item from the next line, that's
> bad.  Maybe it will help to tell it that text on the same line is
> closer than text on another line?

I don't remember all the intricacies of this, but I do remember that it 
is not always easy to decide what menu item to select.  Imagine something 
like this menu fragment, for instance:

  * foo: (foo).    Our Foo.
  !
  * bar: (bar).    Your Bar.

with point at the exclam: which item will you choose?

Another complication is that RET works with both menus and xrefs, so if 
its code is sufficiently generic (i.e. does not depend too much on what
menus look like), it might need thorough rewrite to be much smarter in 
the menu case alone.

I'm not saying that we shouldn't try to make it work in the most 
reasonable fashion inside a menu.  What I'm saying is that solving this 
needs to take into account the complications I pointed out, and also that 
IMHO we should not change what RET does if it cannot find any link nearby.

Re: info

[Richard Stallman]

    I don't remember all the intricacies of this, but I do remember that it 
    is not always easy to decide what menu item to select.  Imagine something 
    like this menu fragment, for instance:

      * foo: (foo).    Our Foo.
      !
      * bar: (bar).    Your Bar.

    with point at the exclam: which item will you choose?

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.

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::

Put point on the `I' of indices.  This does not seem part of the
previous menu item, but it is indented (be it only slightly) and only
separated from the menu item by blank lines.  One can get around that
by deleting the "including blank lines when further indented lines
follow", which would yield Kai's algorithm, but you seem to suggest
that there are instances where such lines should be included.

Sincerely,

Luc.

Re: info

[Richard Stallman]

       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.

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.

Re: info

[Richard Stallman]

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

Any of these three might be good.

Another idea is that any blank line ends the menu item.
That would do the right thing in the examples you showed me,
and it may well be that there are no blank lines in the middle
of single menu items.

Re: info

[Luc Teirlinck]

Richard Stallman wrote:

   Any of these three might be good.

Then I propose to go for solution 1.

That would be the same as the stand-alone behavior (as Eli proposed
earlier), up to the error message.

It would only select a menu item if point is on the same line as the
menu item.

If point is not on such a line and not on a cross-reference, it would
print the error message:
"Point not on reference and no menu item on this line"
(or similar), making it completely clear that just being on a
continuation line is not considered sufficient.

I believe the current stand-alone error message is unclear:
"No cross references in this node."

I could implement the above if one wanted me to do that.  (I guess
that the stand-alone version is too different from the Emacs version
to just copy the code up to the error message, or not?  Even the names
of the functions seem completely different.  Adapting the current
Emacs function seems relatively straightforward.)

   Another idea is that any blank line ends the menu item.
   That would do the right thing in the examples you showed me,
   and it may well be that there are no blank lines in the middle
   of single menu items.

That is essentially the algorithm Kai proposed.

As mentioned, I indeed know of no examples where this malfunctions.
However, Eli seems to feel very uncomfortable about the possibility of
there actually being such examples.  I would not be surprised either.
If any file uses an indentation style that defeats this, then things
could get very bad within that file.

In terms of implementation, it is just a few more lines of code than
the first solution, so that is not the problem.

Sincerely,

Luc.

Re: info

[Eli Zaretskii]

On Sat, 1 Feb 2003, Richard Stallman wrote:

> Another idea is that any blank line ends the menu item.

This criterion alone doesn't seem to cut it.  Here's a fragment from 
Emacs's info/dir file:

  * Ada mode: (ada-mode). Emacs mode for editing Ada code.
  * CC mode: (ccmode).    Emacs mode for editing C, C++, Objective-C,
                            Java, Pike, and IDL code.
  * Ebrowse: (ebrowse).   A C++ class browser for Emacs.
  * IDLWAVE: (idlwave).   Major mode and shell for IDL and WAVE/CL files.

(see the CC Mode item).

So the empty-line-ends-menu-item method should somehow be augmented by 
other means.

Re: info

[Miles Bader]

On Sun, Feb 02, 2003 at 07:44:17AM +0200, Eli Zaretskii wrote:
> > Another idea is that any blank line ends the menu item.
> 
> This criterion alone doesn't seem to cut it.  Here's a fragment from 
> Emacs's info/dir file:
> 
>   * CC mode: (ccmode).    Emacs mode for editing C, C++, Objective-C,
>                             Java, Pike, and IDL code.
>   * Ebrowse: (ebrowse).   A C++ class browser for Emacs.

Um, I think Richard mean a blank line _also_ ends the menu item -- of course
the start of a new menu item would end the old one!

-Miles
-- 
"1971 pickup truck; will trade for guns"

Re: info

[Stefan Monnier]

> Another idea is that any blank line ends the menu item.

That's what the "sorting and duplicate-elimination for dir" code
I installed a few months back does.


	Stefan

Re: info

[Luc Teirlinck]

Stefan Monnier wrote:

   > Another idea is that any blank line ends the menu item.

   That's what the "sorting and duplicate-elimination for dir" code
   I installed a few months back does.

I am starting to lean toward implementing Kay's and Richard's
suggestion.  I have not found any single example defeating it.

Even if something would go wrong, the confusion caused by it (in as
far as RETURN is concerned) would be less than the confusion caused by
the present Emacs behavior.  We are not exactly talking about deleting
directories or such.

Eli is opposed to it, but he seems to have misunderstood the proposal.

The fundamental question is, how likely are we to see something like:

* 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!

Not an actual example, but an example I gave before with some newlines
removed.  Everything depends on the likelihood of such examples
occurring on practice.  Especially the missing newline before the
"Footnotes" line (the only problem) looks ugly to me.  But, are there
any hard stylistic guidelines against writing in such a
blank-line-less style?

I have not really made up my mind one way or the other.  Everything
depends on the above questions.

Sincerely,

Luc.

Re: info

[Luc Teirlinck]

>From my previous message:
   
   But, are there any hard stylistic guidelines against writing in
   such a blank-line-less style?

To be more precise:

Is there a stylistic convention (for info files) that says that free
lines or footnotes need to be separated from menu lines by a blank
line?  Such a convention seems to be implicitly adhered to and things
would look ugly otherwise.

Sincerely,

Luc.

Re: info

[Luc Teirlinck]

>From my previous message:

   Is there a stylistic convention (for info files) that says that free
   lines or footnotes need to be separated from menu lines by a blank
   line?

Meant is: from PRECEDING menu lines

Sincerely,

Luc.

Re: info

[Richard Stallman]

    Not an actual example, but an example I gave before with some newlines
    removed.  Everything depends on the likelihood of such examples
    occurring on practice.  Especially the missing newline before the
    "Footnotes" line (the only problem) looks ugly to me.

I agree, and I would say that is bad Texinfo style.
It is possible that the Texinfo manual says so.
It is also possible that Makeinfo will put blank lines
there, but I am not sure.

We should fix any such manuals.

Re: info

[Eli Zaretskii]

On Tue, 4 Feb 2003, Richard Stallman wrote:

>     Not an actual example, but an example I gave before with some newlines
>     removed.  Everything depends on the likelihood of such examples
>     occurring on practice.  Especially the missing newline before the
>     "Footnotes" line (the only problem) looks ugly to me.
> 
> I agree, and I would say that is bad Texinfo style.
> It is possible that the Texinfo manual says so.

The "Footnotes" line is generated by makeinfo from the @footnote 
directives in the Texinfo source.  So if it stands in the way of what RET 
should do in marginal cases, we should change makeinfo to do what we want 
(and take into account that until the new makeinfo unseats the older 
versions, some manuals will cause Info to fail in these marginal cases).

Re: info

[Luc Teirlinck]

Eli Zaretskii wrote:

   The "Footnotes" line is generated by makeinfo from the @footnote 
   directives in the Texinfo source.  So if it stands in the way of what RET 
   should do in marginal cases, we should change makeinfo to do what we want 
   (and take into account that until the new makeinfo unseats the older 
   versions, some manuals will cause Info to fail in these marginal cases).

We are not just talking about footnotes, but about free lines as well.
Again, not an actual example, but an actual example with a blank line
(as well as some irrelevant lines) removed:
_____________________________________________________________________
Appendices

* Antinews::                Info for users downgrading to Emacs 20.
* GNU Free Documentation License:: The license for this documentation
* GPL::                     Conditions for copying and changing GNU
* Emacs.
* New Symbols::             New functions and variables in Emacs 21.
      --- The Detailed Node Listing ---

Here are other nodes that are inferiors of those already listed,
mentioned here so you can get to them in one step:

Introduction

* Caveats::                 Flaws and a request for help.
* Acknowledgements::        The authors, editors, and sponsors of this
* manual.
_______________________________________________________________________

My comments:

In the actual example, there was a blank line separating
      --- The Detailed Node Listing ---
from the previous line.

Again, I have seen no actual examples without such a blank line and
they would look ugly.  Going to "New Symbols" in the example would not
be that confusing to begin with.  If any examples like this occurred
in the dir file, then there would be worse things to worry about than
that.  If I understood Stefan correctly, his duplicate elimination and
sorting algorithm would very likely carry
      --- The Detailed Node Listing ---
to a place where it would make absolutely no sense, because his
algorithm would consider it part of the "* New Symbols::"-node,
since it is identical to the algorithm proposed by Kai and Richard.
(Stefan can correct me if I misunderstood him.)

I believe that actual occurrence of such (ugly) examples is very
unlikely.

Sincerely,

Luc.

Re: info

[Luc Teirlinck]

Included is a change log entry and patch that implements the new
behavior for RETURN in the Emacs version of info, using the
algorithm suggested by Kai and Richard.

Change log:

2003-02-08  Luc Teirlinck  <teirllm@mail.auburn.edu>

        * info.el (Info-follow-nearest-node): Implement new behavior.

Patch:


===File ~/infodiff==========================================
cd /usr/local/share/emacs/21.3.50/lisp/
diff -c /usr/local/share/emacs/21.3.50/lisp/info.old.el /usr/local/share/emacs/21.3.50/lisp/info.el
*** /usr/local/share/emacs/21.3.50/lisp/info.old.el	Sat Feb  8 20:43:13 2003
--- /usr/local/share/emacs/21.3.50/lisp/info.el	Sat Feb  8 22:12:39 2003
***************
*** 2113,2124 ****
         (Info-next-preorder)))
  
  (defun Info-follow-nearest-node ()
!   "\\<Info-mode-map>Follow a node reference near point.
! Like \\[Info-menu], \\[Info-follow-reference], \\[Info-next], \\[Info-prev] or \\[Info-up] command, depending on where point is.
! If no reference to follow, moves to the next node, or up if none."
    (interactive)
    (or (Info-try-follow-nearest-node)
!       (Info-next-preorder)))
  
  ;; Common subroutine.
  (defun Info-try-follow-nearest-node ()
--- 2113,2134 ----
         (Info-next-preorder)))
  
  (defun Info-follow-nearest-node ()
!   "Follow a node reference near point.
! If point is on a reference, follow that reference.  Otherwise,
! if point is in a menu item description, follow that menu item."
    (interactive)
    (or (Info-try-follow-nearest-node)
!       (when (save-excursion
! 	      (search-backward "\n* menu:" nil t)) 
! 	(save-excursion
! 	  (beginning-of-line)
! 	  (while (not (or (bobp) (looking-at "[^ \t]\\|[ \t]*$")))
! 	    (beginning-of-line 0))
! 	  (when (looking-at "\\* +\\([^\t\n]*\\):")
! 	    (Info-goto-node
! 	     (Info-extract-menu-item (match-string-no-properties 1)))
! 	    t)))
!       (error "Point neither on reference nor in menu item description")))
  
  ;; Common subroutine.
  (defun Info-try-follow-nearest-node ()

Diff finished at Sat Feb  8 22:19:44
============================================================