bug#9528: 24.0.50; Info navigation

bug#9528: 24.0.50; Info navigation

[Dani Moncayo]

Hi,

I noticed several malfunctions in info navigation commands.

The following recipes start from "emacs -Q":

------------------------------------------------
1. Eval: (info "(elisp)Macros")
2. Type: <DEL>
 --> Go to node "(elisp)Related Topics" (OK).
3. Type: l
 --> (Expected) Go to the last-visited info node (i.e., "(elisp)Macros").
 --> (Observed) Go to node "(elisp)Functions".
------------------------------------------------
1. Eval: (info "(elisp)Macros")
2. Move point to line 21 (* Menu:).
3. Type: <DEL>
 --> (Expected) Go to node "(elisp)Related Topics".
 --> (Observed) Go to node "(elisp)Process Internals".
------------------------------------------------
1. Eval: (info "(elisp)Macros")
2. Move point to line 22 (* Simple Macro).
3. Type: <DEL>
 --> (Expected) Go to node "(elisp)Related Topics".
 --> (Observed) Go to node "(elisp)Simple Macro".
------------------------------------------------


Note: The behavior I expect is based on what I've read in info-mode
help (C-h i ?).


In GNU Emacs 24.0.50.1 (i386-mingw-nt6.1.7601)
 of 2011-09-12 on 3249CTO
Windowing system distributor `Microsoft Corp.', version 6.1.7601
configured using `configure --with-gcc (4.5) --no-opt'

-- 
Dani Moncayo

bug#9528: 24.0.50; Info navigation

[Dani Moncayo]

> 2. Move point to line 22 (* Simple Macro).
                        ^^

Actually, that line is the 23rd. Sorry.


-- 
Dani Moncayo

bug#9528: 24.0.50; Info navigation

[Juri Linkov]

> I noticed several malfunctions in info navigation commands.
>
> The following recipes start from "emacs -Q":
>
> ------------------------------------------------
> 1. Eval: (info "(elisp)Macros")
> 2. Type: <DEL>
>  --> Go to node "(elisp)Related Topics" (OK).
> 3. Type: l
>  --> (Expected) Go to the last-visited info node (i.e., "(elisp)Macros").
>  --> (Observed) Go to node "(elisp)Functions".
> ------------------------------------------------
> 1. Eval: (info "(elisp)Macros")
> 2. Move point to line 21 (* Menu:).
> 3. Type: <DEL>
>  --> (Expected) Go to node "(elisp)Related Topics".
>  --> (Observed) Go to node "(elisp)Process Internals".
> ------------------------------------------------
> 1. Eval: (info "(elisp)Macros")
> 2. Move point to line 22 (* Simple Macro).
> 3. Type: <DEL>
>  --> (Expected) Go to node "(elisp)Related Topics".
>  --> (Observed) Go to node "(elisp)Simple Macro".
> ------------------------------------------------
>
> Note: The behavior I expect is based on what I've read in info-mode
> help (C-h i ?).

This looks like a use-case similar to http://debbugs.gnu.org/208
I think it could be fixed the same way.

bug#9528: 24.0.50; Info navigation

[Juri Linkov]

>> 2. Move point to line 22 (* Simple Macro).
>                         ^^
>
> Actually, that line is the 23rd. Sorry.

BTW, `M-g g' (`goto-line') doesn't work in Info.
Should be fixed too.

bug#9528: 24.0.50; Info navigation

[Juri Linkov]

> I noticed several malfunctions in info navigation commands.
>
> The following recipes start from "emacs -Q":
>
> ------------------------------------------------
> 1. Eval: (info "(elisp)Macros")
> 2. Type: <DEL>
>  --> Go to node "(elisp)Related Topics" (OK).
> 3. Type: l
>  --> (Expected) Go to the last-visited info node (i.e., "(elisp)Macros").
>  --> (Observed) Go to node "(elisp)Functions".

Fixed the same way as bug#208.

> ------------------------------------------------
> 1. Eval: (info "(elisp)Macros")
> 2. Move point to line 21 (* Menu:).
> 3. Type: <DEL>
>  --> (Expected) Go to node "(elisp)Related Topics".
>  --> (Observed) Go to node "(elisp)Process Internals".

Fixed this bug as well.

> ------------------------------------------------
> 1. Eval: (info "(elisp)Macros")
> 2. Move point to line 22 (* Simple Macro).
> 3. Type: <DEL>
>  --> (Expected) Go to node "(elisp)Related Topics".
>  --> (Observed) Go to node "(elisp)Simple Macro".

Sorry, I can't change this because this behavior is explicitly
implemented in Info, so it's not a bug.

> ------------------------------------------------
>
> Note: The behavior I expect is based on what I've read in info-mode
> help (C-h i ?).

bug#9528: 24.0.50; Info navigation

[Dani Moncayo]

>> ------------------------------------------------
>> 1. Eval: (info "(elisp)Macros")
>> 2. Type: <DEL>
>>  --> Go to node "(elisp)Related Topics" (OK).
>> 3. Type: l
>>  --> (Expected) Go to the last-visited info node (i.e., "(elisp)Macros").
>>  --> (Observed) Go to node "(elisp)Functions".
>
> Fixed the same way as bug#208.

Tested.  Thanks.

>> ------------------------------------------------
>> 1. Eval: (info "(elisp)Macros")
>> 2. Move point to line 21 (* Menu:).
>> 3. Type: <DEL>
>>  --> (Expected) Go to node "(elisp)Related Topics".
>>  --> (Observed) Go to node "(elisp)Process Internals".
>
> Fixed this bug as well.

Tested.  Thanks.

>> ------------------------------------------------
>> 1. Eval: (info "(elisp)Macros")
>> 2. Move point to line 22 (* Simple Macro).
>> 3. Type: <DEL>
>>  --> (Expected) Go to node "(elisp)Related Topics".
>>  --> (Observed) Go to node "(elisp)Simple Macro".
>
> Sorry, I can't change this because this behavior is explicitly
> implemented in Info, so it's not a bug.

Then I have a couple of things to say about this:
* The current behavior is not documented AFAIK [1].
* Even if the behavior was documented, it is not desirable (IMO),
because we already have a specific command to follow a
cross-reference: <RET>.  Thus, if I type <DEL> in an info buffer, I'd
like to see the same behavior (going back) regardless of whether the
point is on a cross-reference or not.  It is much clearer to keep
these behaviors separated.

>>> 2. Move point to line 22 (* Simple Macro).
>>
>> Actually, that line is the 23rd. Sorry.
>
> BTW, `M-g g' (`goto-line') doesn't work in Info.
> Should be fixed too.

Of course I agree.  `goto-line' should be consistent with the line
numbers showed in the modeline, regardless of whether the buffer is
narrowed or not.  The current behavior is confusing for users, I
think.


Footnotes:
[1] The info mode help (C-h i ?) says this about <DEL>: "Normally,
scroll backward.  If the beginning of the buffer is already visible,
try to go to the previous menu entry, or up if the is none.".

-- 
Dani Moncayo

bug#9528: 24.0.50; Info navigation

[Eli Zaretskii]

> Date: Mon, 19 Sep 2011 10:14:24 +0200
> From: Dani Moncayo <dmoncayo@gmail.com>
> Cc: 9528@debbugs.gnu.org
> 
> >> ------------------------------------------------
> >> 1. Eval: (info "(elisp)Macros")
> >> 2. Type: <DEL>
> >>  --> Go to node "(elisp)Related Topics" (OK).
> >> 3. Type: l
> >>  --> (Expected) Go to the last-visited info node (i.e., "(elisp)Macros").
> >>  --> (Observed) Go to node "(elisp)Functions".
> >
> > Fixed the same way as bug#208.
> 
> Tested.  Thanks.

I'm sorry, but IMO this change should be reverted, because the
original behavior is consistent with the stand-alone Info reader (and
with my finger memory).

The reason it goes to Functions is because <DEL> from Macros visited 2
nodes: first Functions (it's Prev for Macros, see the header line when
you are in Macros), and then Related Topics.  So typing l goes back to
Functions.  Type one more l and you are in Macros.

Note that "C-h l" does not say "the last node _presented_", it says
"the last node _visited_".

Even if the result is unexpected by someone who is not used to Info, I
think it's Baaad to have Emacs's Info reader behave differently than
the stand-alone reader.

> >> 1. Eval: (info "(elisp)Macros")
> >> 2. Move point to line 22 (* Simple Macro).
> >> 3. Type: <DEL>
> >>  --> (Expected) Go to node "(elisp)Related Topics".
> >>  --> (Observed) Go to node "(elisp)Simple Macro".
> >
> > Sorry, I can't change this because this behavior is explicitly
> > implemented in Info, so it's not a bug.

I think it's a bug, because the stand-alone Info reader goes to
Related Topics.

bug#9528: 24.0.50; Info navigation

[Dani Moncayo]

>> >> ------------------------------------------------
>> >> 1. Eval: (info "(elisp)Macros")
>> >> 2. Type: <DEL>
>> >>  --> Go to node "(elisp)Related Topics" (OK).
>> >> 3. Type: l
>> >>  --> (Expected) Go to the last-visited info node (i.e., "(elisp)Macros").
>> >>  --> (Observed) Go to node "(elisp)Functions".
>> >
>> > Fixed the same way as bug#208.
>>
>> Tested.  Thanks.
>
> I'm sorry, but IMO this change should be reverted, because the
> original behavior is consistent with the stand-alone Info reader (and
> with my finger memory).
>
> The reason it goes to Functions is because <DEL> from Macros visited 2
> nodes: first Functions (it's Prev for Macros, see the header line when
> you are in Macros), and then Related Topics.  So typing l goes back to
> Functions.  Type one more l and you are in Macros.
>
> Note that "C-h l" does not say "the last node _presented_", it says
> "the last node _visited_".

IMO, users should not care about the underlying implementation, i.e,
in the example below, I have _seen_ only two nodes, so that when I
type `l' in the second one, I'd expect to jump back to the first one.

> Even if the result is unexpected by someone who is not used to Info, I
> think it's Baaad to have Emacs's Info reader behave differently than
> the stand-alone reader.

That divergence is bad, obviously.  But IMO, If the change is
considered good, should be made both in Emacs and the stand-alone
reader.  (I don't know who maintains the latter).

-- 
Dani Moncayo

bug#9528: 24.0.50; Info navigation

[Eli Zaretskii]

> Date: Mon, 19 Sep 2011 12:20:55 +0200
> From: Dani Moncayo <dmoncayo@gmail.com>
> Cc: juri@jurta.org, 9528@debbugs.gnu.org
> 
> > The reason it goes to Functions is because <DEL> from Macros visited 2
> > nodes: first Functions (it's Prev for Macros, see the header line when
> > you are in Macros), and then Related Topics.  So typing l goes back to
> > Functions.  Type one more l and you are in Macros.
> >
> > Note that "C-h l" does not say "the last node _presented_", it says
> > "the last node _visited_".
> 
> IMO, users should not care about the underlying implementation, i.e,
> in the example below, I have _seen_ only two nodes, so that when I
> type `l' in the second one, I'd expect to jump back to the first one.

It's not the implementation, it's part of documented behavior of DEL:

  Scroll one screenful back in Info, considering all nodes as one
  sequence                           ----------------------------
  --------

IOW, DEL (and SPC) move between nodes of the node tree in the
depth-first-search order.  And l moves back in the same order.

> > Even if the result is unexpected by someone who is not used to Info, I
> > think it's Baaad to have Emacs's Info reader behave differently than
> > the stand-alone reader.
> 
> That divergence is bad, obviously.  But IMO, If the change is
> considered good, should be made both in Emacs and the stand-alone
> reader.

Feel free to suggest this change on the Texinfo mailing list.

bug#9528: 24.0.50; Info navigation

[Dani Moncayo]

> It's not the implementation, it's part of documented behavior of DEL:
>
>  Scroll one screenful back in Info, considering all nodes as one
>  sequence                           ----------------------------
>  --------

As I see it, considering all nodes as one sequence, the node just
before "Macros" is "Related Topics", not "Functions".  IOW, <DEL>
should show the nodes in the same sequential order that appear in the
printed version of the manual, and likewise for <SPC>.

Then `l' should jump back to previously visited (well, presented to
the user) nodes.

-- 
Dani Moncayo

bug#9528: 24.0.50; Info navigation

[Juri Linkov]

> Note that "C-h l" does not say "the last node _presented_", it says
> "the last node _visited_".

(info "(info-stnd) Node Commands") says:

`l' (`history-node')
     Pop the most recently _selected_ node in this window from the node
     history.

So it's a bug in the stand-alone reader because it returns to the node
that was not _recently selected_.  This behavior is confusing for users.

>> >> 1. Eval: (info "(elisp)Macros")
>> >> 2. Move point to line 22 (* Simple Macro).
>> >> 3. Type: <DEL>
>> >>  --> (Expected) Go to node "(elisp)Related Topics".
>> >>  --> (Observed) Go to node "(elisp)Simple Macro".
>> >
>> > Sorry, I can't change this because this behavior is explicitly
>> > implemented in Info, so it's not a bug.
>
> I think it's a bug, because the stand-alone Info reader goes to
> Related Topics.

I agree that it looks like a bug, but I don't understand why it's coded
explicitly that way.  Perhaps the intention was to implement this behavior
only when the value of `Info-scroll-prefer-subnodes' is non-nil?

bug#9528: 24.0.50; Info navigation

[Eli Zaretskii]

> Date: Mon, 19 Sep 2011 12:49:09 +0200
> From: Dani Moncayo <dmoncayo@gmail.com>
> Cc: juri@jurta.org, 9528@debbugs.gnu.org
> 
> > It's not the implementation, it's part of documented behavior of DEL:
> >
> >  Scroll one screenful back in Info, considering all nodes as one
> >  sequence                           ----------------------------
> >  --------
> 
> As I see it, considering all nodes as one sequence, the node just
> before "Macros" is "Related Topics", not "Functions".

Not in depth-first-search order, it isn't.

bug#9528: 24.0.50; Info navigation

[Eli Zaretskii]

> From: Juri Linkov <juri@jurta.org>
> Cc: Dani Moncayo <dmoncayo@gmail.com>,  9528@debbugs.gnu.org
> Date: Mon, 19 Sep 2011 14:16:46 +0300
> 
> > Note that "C-h l" does not say "the last node _presented_", it says
> > "the last node _visited_".
> 
> (info "(info-stnd) Node Commands") says:
> 
> `l' (`history-node')
>      Pop the most recently _selected_ node in this window from the node
>      history.

That's a documentation bug.  See the manual for the correct
description.

Please revert the change.

> >> >> 1. Eval: (info "(elisp)Macros")
> >> >> 2. Move point to line 22 (* Simple Macro).
> >> >> 3. Type: <DEL>
> >> >>  --> (Expected) Go to node "(elisp)Related Topics".
> >> >>  --> (Observed) Go to node "(elisp)Simple Macro".
> >> >
> >> > Sorry, I can't change this because this behavior is explicitly
> >> > implemented in Info, so it's not a bug.
> >
> > I think it's a bug, because the stand-alone Info reader goes to
> > Related Topics.
> 
> I agree that it looks like a bug, but I don't understand why it's coded
> explicitly that way.  Perhaps the intention was to implement this behavior
> only when the value of `Info-scroll-prefer-subnodes' is non-nil?

Maybe, I cannot say.  We can condition it on that variable.

bug#9528: 24.0.50; Info navigation

[Dani Moncayo]

>> > It's not the implementation, it's part of documented behavior of DEL:
>> >
>> >  Scroll one screenful back in Info, considering all nodes as one
>> >  sequence                           ----------------------------
>> >  --------
>>
>> As I see it, considering all nodes as one sequence, the node just
>> before "Macros" is "Related Topics", not "Functions".
>
> Not in depth-first-search order, it isn't.

In that order maybe not, but I think the intended order is not that,
but "sequential", as described in (info "(info)Help-^L"):

>    <SPC> and <DEL> not only move forward and backward through the
> current node.  They also move between nodes.  <SPC> at the end of a
> node moves to the next node; <DEL> (or <BACKSPACE>) at the beginning of
> a node moves to the previous node.  In effect, these commands scroll
> through all the nodes in an Info file as a single logical sequence.
> You can read an entire manual top to bottom by just typing <SPC>, and
> move backward through the entire manual from bottom to top by typing
> <DEL> (or <BACKSPACE>).
>
>    In this sequence, a node's subnodes appear following their parent.
> If a node has a menu, <SPC> takes you into the subnodes listed in the
> menu, one by one.  Once you reach the end of a node, and have seen all
> of its subnodes, <SPC> takes you to the next node or to the parent's
> next node.

According to that sequential order, as I said, the previous node of
"Macros" is "Retated Topics", not "Functions".

-- 
Dani Moncayo

bug#9528: 24.0.50; Info navigation

[Dani Moncayo]

>> > Note that "C-h l" does not say "the last node _presented_", it says
>> > "the last node _visited_".
>>
>> (info "(info-stnd) Node Commands") says:
>>
>> `l' (`history-node')
>>      Pop the most recently _selected_ node in this window from the node
>>      history.
>
> That's a documentation bug.  See the manual for the correct
> description.


The same behavior is documented in (info "(info)Help-Int"):

>    If you have been moving around to different nodes and wish to
> retrace your steps, the `l' command (`l' for "last") will do that, one
> node-step at a time.  As you move from node to node, Info records the
> nodes where you have been in a special history list.  The `l' command
> revisits nodes in the history list; each successive `l' command moves
> one step back through the history.

Note the "you have been in".  IMO, it is clear that it refers to nodes
you have selected, as Juri says.  IMHO, that is what makes sense for
users.

-- 
Dani Moncayo

bug#9528: 24.0.50; Info navigation

[Eli Zaretskii]

> Date: Mon, 19 Sep 2011 14:14:26 +0200
> From: Dani Moncayo <dmoncayo@gmail.com>
> Cc: juri@jurta.org, 9528@debbugs.gnu.org
> 
> >> > It's not the implementation, it's part of documented behavior of DEL:
> >> >
> >> >  Scroll one screenful back in Info, considering all nodes as one
> >> >  sequence                           ----------------------------
> >> >  --------
> >>
> >> As I see it, considering all nodes as one sequence, the node just
> >> before "Macros" is "Related Topics", not "Functions".
> >
> > Not in depth-first-search order, it isn't.
> 
> In that order maybe not, but I think the intended order is not that,
> but "sequential", as described in (info "(info)Help-^L"):

An Info manual has a tree structure, so sequential order is not well
defined.  If you read the description in Help-^L, you will see that it
describes depth-first-search:

     In this sequence, a node's subnodes appear following their parent.
  If a node has a menu, <SPC> takes you into the subnodes listed in the
  menu, one by one.  Once you reach the end of a node, and have seen all
  of its subnodes, <SPC> takes you to the next node or to the parent's
  next node.

bug#9528: 24.0.50; Info navigation

[Dani Moncayo]

>> >> As I see it, considering all nodes as one sequence, the node just
>> >> before "Macros" is "Related Topics", not "Functions".
>> >
>> > Not in depth-first-search order, it isn't.
>>
>> In that order maybe not, but I think the intended order is not that,
>> but "sequential", as described in (info "(info)Help-^L"):
>
> An Info manual has a tree structure, so sequential order is not well
> defined.  If you read the description in Help-^L, you will see that it
> describes depth-first-search:
>
>     In this sequence, a node's subnodes appear following their parent.
>  If a node has a menu, <SPC> takes you into the subnodes listed in the
>  menu, one by one.  Once you reach the end of a node, and have seen all
>  of its subnodes, <SPC> takes you to the next node or to the parent's
>  next node.

I understand it.  So according to that:
* <SPC> in node "Related Topics" should take you to node "Macros".
* Conversely, <DEL> in node "Macros" should take you to "Related Topics".

Therefore, if I've jumped from "Macros" to "Related Topics" and then I
type `l', I obviously expect to jump back to "Macros", which is the
last node I've selected.

-- 
Dani Moncayo

bug#9528: 24.0.50; Info navigation

[Juri Linkov]

>> (info "(info-stnd) Node Commands") says:
>>
>> `l' (`history-node')
>>      Pop the most recently _selected_ node in this window from the node
>>      history.
>
> That's a documentation bug.  See the manual for the correct
> description.

Since users are confused by this behavior then maybe we should add an option
to be able to configure it?

>> I agree that it looks like a bug, but I don't understand why it's coded
>> explicitly that way.  Perhaps the intention was to implement this behavior
>> only when the value of `Info-scroll-prefer-subnodes' is non-nil?
>
> Maybe, I cannot say.  We can condition it on that variable.

Ok, will do that.

bug#9528: 24.0.50; Info navigation

[Stefan Monnier]

FWIW, I'm with Dani on this one: maybe jumping back to the intermediate
"Functions" node makes sense for deep reasons, but there are good
superficial reasons to ignore this internal node for `l'.
And Emacs (and I think UIs in general) likes "superficial".


        Stefan

bug#9528: 24.0.50; Info navigation

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Dani Moncayo <dmoncayo@gmail.com>,  9528@debbugs.gnu.org
> Date: Mon, 19 Sep 2011 10:24:12 -0400
> 
> FWIW, I'm with Dani on this one: maybe jumping back to the intermediate
> "Functions" node makes sense for deep reasons, but there are good
> superficial reasons to ignore this internal node for `l'.

Then we will have to disagree.

But I beg you to please leave the traditional operation of `l' alone.
If we want to cater to users who are confused by that, let's have a
separate command.  We can bind it to something users nowadays expect,
like M-<left>, and also to the "go back in history" button on the tool
bar.  Just let's not change what `l' does, as long as the stand-alone
reader works like that.

bug#9528: 24.0.50; Info navigation

[Eli Zaretskii]

> From: Juri Linkov <juri@jurta.org>
> Cc: dmoncayo@gmail.com,  9528@debbugs.gnu.org
> Date: Mon, 19 Sep 2011 17:23:05 +0300
> 
> >> (info "(info-stnd) Node Commands") says:
> >>
> >> `l' (`history-node')
> >>      Pop the most recently _selected_ node in this window from the node
> >>      history.
> >
> > That's a documentation bug.  See the manual for the correct
> > description.
> 
> Since users are confused by this behavior then maybe we should add an option
> to be able to configure it?

Either that or have a separate command, bound to some other key, as I
expect not many modern users will miss the `l' bindings, only old
farts such as myself.

If we go with an option, you can even set it to skip intermediate
nodes by default.  I don't care, as long as I can have my bad habits
back at a price of some customization.

> >> I agree that it looks like a bug, but I don't understand why it's coded
> >> explicitly that way.  Perhaps the intention was to implement this behavior
> >> only when the value of `Info-scroll-prefer-subnodes' is non-nil?
> >
> > Maybe, I cannot say.  We can condition it on that variable.
> 
> Ok, will do that.

Thanks.

bug#9528: 24.0.50; Info navigation

[Stefan Monnier]

> But I beg you to please leave the traditional operation of `l' alone.
> If we want to cater to users who are confused by that, let's have a
> separate command.  We can bind it to something users nowadays expect,
> like M-<left>, and also to the "go back in history" button on the tool
> bar.  Just let's not change what `l' does, as long as the stand-alone
> reader works like that.

The difference is much too subtle to justify two different commands (I
can't think of any single user who'd ever choose between the two
commands).
So if you really insist on having your behavior, then add a custom var
(which should default to follow the superficial behavior), which you can
then set in your .emacs.


        Stefan

bug#9528: 24.0.50; Info navigation

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: dmoncayo@gmail.com,  9528@debbugs.gnu.org
> Date: Mon, 19 Sep 2011 12:41:18 -0400
> 
> So if you really insist on having your behavior, then add a custom var
> (which should default to follow the superficial behavior), which you can
> then set in your .emacs.

Fine with me.

bug#9528: 24.0.50; Info navigation

[Juri Linkov]

>> So if you really insist on having your behavior, then add a custom var
>> (which should default to follow the superficial behavior), which you can
>> then set in your .emacs.
>
> Fine with me.

Do you think such a custom var should have a broad definition to provide
complete compatibility in all functionality with the stand-alone reader
or be specific just wrt the behavior of `l'?

bug#9528: 24.0.50; Info navigation

[Eli Zaretskii]

> From: Juri Linkov <juri@jurta.org>
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>,  9528@debbugs.gnu.org
> Date: Mon, 19 Sep 2011 21:49:39 +0300
> 
> >> So if you really insist on having your behavior, then add a custom var
> >> (which should default to follow the superficial behavior), which you can
> >> then set in your .emacs.
> >
> > Fine with me.
> 
> Do you think such a custom var should have a broad definition to provide
> complete compatibility in all functionality with the stand-alone reader
> or be specific just wrt the behavior of `l'?

I'm not aware of any other compatibility issues.  If there are one or
two more, IMO it isn't worth a single option for all of them.

bug#9528: 24.0.50; Info navigation

[Juri Linkov]

>> >> >> 1. Eval: (info "(elisp)Macros")
>> >> >> 2. Move point to line 22 (* Simple Macro).
>> >> >> 3. Type: <DEL>
>> >> >>  --> (Expected) Go to node "(elisp)Related Topics".
>> >> >>  --> (Observed) Go to node "(elisp)Simple Macro".
>> >> >
>> >> > Sorry, I can't change this because this behavior is explicitly
>> >> > implemented in Info, so it's not a bug.
>> >
>> > I think it's a bug, because the stand-alone Info reader goes to
>> > Related Topics.
>>
>> I agree that it looks like a bug, but I don't understand why it's coded
>> explicitly that way.  Perhaps the intention was to implement this behavior
>> only when the value of `Info-scroll-prefer-subnodes' is non-nil?
>
> Maybe, I cannot say.  We can condition it on that variable.

Yes, this behavior is documented in the docstring of `Info-scroll-down':
"If point is within the menu of a node, and `Info-scroll-prefer-subnodes'
 is non-nil, this goes to its last subnode."

So I fixed it to work according to the docstring.

bug#9528: 24.0.50; Info navigation

[Juri Linkov]

>> >> So if you really insist on having your behavior, then add a custom
>> >> var (which should default to follow the superficial behavior),
>> >> which you can then set in your .emacs.
>> >
>> > Fine with me.
>>
>> Do you think such a custom var should have a broad definition to provide
>> complete compatibility in all functionality with the stand-alone reader
>> or be specific just wrt the behavior of `l'?
>
> I'm not aware of any other compatibility issues.

I found another compatibility issue.

1. Run `emacs -Q'
2. `C-h i m elisp RET g Macros RET'
3. `[' (`Info-backward-node') goes to "Related Topics".
4. `l' goes back to the previously selected node "Macros".

1. Run `info'
2. `m elisp RET g Macros RET'
3. `[' (`Info-backward-node') goes to "Related Topics".
4. `l' goes to the node "Functions", not "Macros".

The behavior of the Emacs Info reader to skip intermediate nodes by default
dates back to the first version of info.el at 1991-07-13.

If you think that behavior of the stand-alone Info reader
is more traditional, we could install this patch:

=== modified file 'lisp/info.el'
--- lisp/info.el	2011-09-18 18:56:22 +0000
+++ lisp/info.el	2011-09-20 16:12:12 +0000
@@ -52,6 +52,15 @@ (defvar Info-history-list nil
   "List of all Info nodes user has visited.
 Each element of the list is a list (FILENAME NODENAME).")
 
+(defcustom Info-history-skip-intermediate-nodes t
+  "Non-nil means don't record intermediate Info nodes to the history.
+Intermediate Info nodes are nodes visited by Info internally in the process of
+searching the node to display.  Intermediate nodes are not presented
+to the user."
+  :type 'boolean
+  :group 'info
+  :version "24.1")
+
 (defcustom Info-enable-edit nil
   "Non-nil means the \\<Info-mode-map>\\[Info-edit] command in Info can edit the current node.
 This is convenient if you want to write Info files by hand.
@@ -2673,10 +2682,13 @@ (defun Info-forward-node (&optional not-
 				   "top")))
 	   (let ((old-node Info-current-node))
 	     (Info-up)
-	     (let (Info-history success)
+	     (let ((old-history Info-history)
+		   success)
 	       (unwind-protect
 		   (setq success (Info-forward-node t nil no-error))
-		 (or success (Info-goto-node old-node))))))
+		 (or success (Info-goto-node old-node)))
+	       (if Info-history-skip-intermediate-nodes
+		   (setq Info-history old-history)))))
 	  (no-error nil)
 	  (t (error "No pointer forward from this node")))))
 
@@ -2698,10 +2710,12 @@ (defun Info-backward-node ()
 	   ;; If we move back at the same level,
 	   ;; go down to find the last subnode*.
 	   (Info-prev)
-	   (let (Info-history)
+	   (let ((old-history Info-history))
 	     (while (and (not (Info-index-node))
 			 (save-excursion (search-forward "\n* Menu:" nil t)))
-	       (Info-goto-node (Info-extract-menu-counting nil)))))
+	       (Info-goto-node (Info-extract-menu-counting nil)))
+	     (if Info-history-skip-intermediate-nodes
+		 (setq Info-history old-history))))
 	  (t
 	   (error "No pointer backward from this node")))))
 
@@ -2757,8 +2771,10 @@ (defun Info-next-preorder ()
 	 ;; Since logically we are done with the node with that menu,
 	 ;; move on from it.  But don't add intermediate nodes
 	 ;; to the history on recursive calls.
-	 (let (Info-history)
-	   (Info-next-preorder)))
+	 (let ((old-history Info-history))
+	   (Info-next-preorder)
+	   (if Info-history-skip-intermediate-nodes
+	       (setq Info-history old-history))))
 	(t
 	 (error "No more nodes"))))
 
@@ -2771,24 +2787,28 @@ (defun Info-last-preorder ()
 	  ;; so we can scroll back through it.
 	  (goto-char (point-max)))
 	 ;; Keep going down, as long as there are nested menu nodes.
-	 (let (Info-history) ; Don't add intermediate nodes to the history.
+	 (let ((old-history Info-history))
 	   (while (Info-no-error
 		   (Info-last-menu-item)
 		   ;; If we go down a menu item, go to the end of the node
 		   ;; so we can scroll back through it.
-		   (goto-char (point-max)))))
+		   (goto-char (point-max))))
+	   (if Info-history-skip-intermediate-nodes
+	       (setq Info-history old-history)))
 	 (recenter -1))
 	((and (Info-no-error (Info-extract-pointer "prev"))
 	      (not (equal (Info-extract-pointer "up")
 			  (Info-extract-pointer "prev"))))
 	 (Info-no-error (Info-prev))
 	 (goto-char (point-max))
-	 (let (Info-history) ; Don't add intermediate nodes to the history.
+	 (let ((old-history Info-history))
 	   (while (Info-no-error
 		   (Info-last-menu-item)
 		   ;; If we go down a menu item, go to the end of the node
 		   ;; so we can scroll back through it.
-		   (goto-char (point-max)))))
+		   (goto-char (point-max))))
+	   (if Info-history-skip-intermediate-nodes
+	       (setq Info-history old-history)))
 	 (recenter -1))
 	((Info-no-error (Info-up t))
 	 (goto-char (point-min))

bug#9528: 24.0.50; Info navigation

[Eli Zaretskii]

> From: Juri Linkov <juri@jurta.org>
> Cc: monnier@iro.umontreal.ca,  9528@debbugs.gnu.org
> Date: Tue, 20 Sep 2011 19:30:01 +0300
> 
> 1. Run `emacs -Q'
> 2. `C-h i m elisp RET g Macros RET'
> 3. `[' (`Info-backward-node') goes to "Related Topics".
> 4. `l' goes back to the previously selected node "Macros".
> 
> 1. Run `info'
> 2. `m elisp RET g Macros RET'
> 3. `[' (`Info-backward-node') goes to "Related Topics".
> 4. `l' goes to the node "Functions", not "Macros".
> 
> The behavior of the Emacs Info reader to skip intermediate nodes by default
> dates back to the first version of info.el at 1991-07-13.

You mean, when `[' is used?  Because otherwise, the Emacs behavior
with `l' was like the stand-alone Info, until you changed that a day
or two ago, right?

> If you think that behavior of the stand-alone Info reader
> is more traditional, we could install this patch:

Yes, assuming I understand correctly what you are saying, see above.

bug#9528: 24.0.50; Info navigation

[Juri Linkov]

>> 1. Run `emacs -Q'
>> 2. `C-h i m elisp RET g Macros RET'
>> 3. `[' (`Info-backward-node') goes to "Related Topics".
>> 4. `l' goes back to the previously selected node "Macros".
>>
>> 1. Run `info'
>> 2. `m elisp RET g Macros RET'
>> 3. `[' (`Info-backward-node') goes to "Related Topics".
>> 4. `l' goes to the node "Functions", not "Macros".
>>
>> The behavior of the Emacs Info reader to skip intermediate nodes by default
>> dates back to the first version of info.el at 1991-07-13.
>
> You mean, when `[' is used?  Because otherwise, the Emacs behavior
> with `l' was like the stand-alone Info, until you changed that a day
> or two ago, right?

Two days ago I changed the behavior of `DEL l'.  `[ l' in Emacs
has been working unlike the stand-alone Info since at least 1991.

bug#9528: 24.0.50; Info navigation

[Eli Zaretskii]

> From: Juri Linkov <juri@jurta.org>
> Cc: monnier@iro.umontreal.ca,  9528@debbugs.gnu.org
> Date: Tue, 20 Sep 2011 20:50:45 +0300
> 
> Two days ago I changed the behavior of `DEL l'.  `[ l' in Emacs
> has been working unlike the stand-alone Info since at least 1991.

Then I think that both behaviors should be controlled by the same
option, like in the change you suggested.

Thanks.

bug#9528: 24.0.50; Info navigation

[Juri Linkov]

> Then I think that both behaviors should be controlled by the same
> option, like in the change you suggested.
>
> Thanks.

Installed and closed.