GNU bug report logs - #9528
24.0.50; Info navigation

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 9528 in the body.
You can then email your comments to 9528 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Dani Moncayo <dmoncayo <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.0.50; Info navigation
Date: Sat, 17 Sep 2011 12:54:50 +0200

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

Message #8 received at 9528 <at> debbugs.gnu.org (full text, mbox):

From: Dani Moncayo <dmoncayo <at> gmail.com>
To: 9528 <at> debbugs.gnu.org
Subject: Re: bug#9528: 24.0.50; Info navigation
Date: Sat, 17 Sep 2011 13:01:51 +0200

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

Actually, that line is the 23rd. Sorry.


-- 
Dani Moncayo

Message #11 received at 9528 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> jurta.org>
To: Dani Moncayo <dmoncayo <at> gmail.com>
Cc: 9528 <at> debbugs.gnu.org
Subject: Re: bug#9528: 24.0.50; Info navigation
Date: Sat, 17 Sep 2011 21:00:47 +0300

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

Message #14 received at 9528 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> jurta.org>
To: Dani Moncayo <dmoncayo <at> gmail.com>
Cc: 9528 <at> debbugs.gnu.org
Subject: Re: bug#9528: 24.0.50; Info navigation
Date: Sat, 17 Sep 2011 21:02:34 +0300

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

Message #17 received at 9528 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> jurta.org>
To: Dani Moncayo <dmoncayo <at> gmail.com>
Cc: 9528 <at> debbugs.gnu.org
Subject: Re: bug#9528: 24.0.50; Info navigation
Date: Sun, 18 Sep 2011 23:14:52 +0300

> 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 ?).

Message #20 received at 9528 <at> debbugs.gnu.org (full text, mbox):

From: Dani Moncayo <dmoncayo <at> gmail.com>
To: Juri Linkov <juri <at> jurta.org>
Cc: 9528 <at> debbugs.gnu.org
Subject: Re: bug#9528: 24.0.50; Info navigation
Date: Mon, 19 Sep 2011 10:14:24 +0200

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

Message #23 received at 9528 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dani Moncayo <dmoncayo <at> gmail.com>
Cc: juri <at> jurta.org, 9528 <at> debbugs.gnu.org
Subject: Re: bug#9528: 24.0.50; Info navigation
Date: Mon, 19 Sep 2011 05:49:25 -0400

> Date: Mon, 19 Sep 2011 10:14:24 +0200
> From: Dani Moncayo <dmoncayo <at> gmail.com>
> Cc: 9528 <at> 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.

Message #26 received at 9528 <at> debbugs.gnu.org (full text, mbox):

From: Dani Moncayo <dmoncayo <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: juri <at> jurta.org, 9528 <at> debbugs.gnu.org
Subject: Re: bug#9528: 24.0.50; Info navigation
Date: Mon, 19 Sep 2011 12:20:55 +0200

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

Message #29 received at 9528 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dani Moncayo <dmoncayo <at> gmail.com>
Cc: juri <at> jurta.org, 9528 <at> debbugs.gnu.org
Subject: Re: bug#9528: 24.0.50; Info navigation
Date: Mon, 19 Sep 2011 06:37:02 -0400

> Date: Mon, 19 Sep 2011 12:20:55 +0200
> From: Dani Moncayo <dmoncayo <at> gmail.com>
> Cc: juri <at> jurta.org, 9528 <at> 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.

Message #32 received at 9528 <at> debbugs.gnu.org (full text, mbox):

From: Dani Moncayo <dmoncayo <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: juri <at> jurta.org, 9528 <at> debbugs.gnu.org
Subject: Re: bug#9528: 24.0.50; Info navigation
Date: Mon, 19 Sep 2011 12:49:09 +0200

> 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

Message #35 received at 9528 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> jurta.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 9528 <at> debbugs.gnu.org, Dani Moncayo <dmoncayo <at> gmail.com>
Subject: Re: bug#9528: 24.0.50; Info navigation
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.

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?

Message #38 received at 9528 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dani Moncayo <dmoncayo <at> gmail.com>
Cc: juri <at> jurta.org, 9528 <at> debbugs.gnu.org
Subject: Re: bug#9528: 24.0.50; Info navigation
Date: Mon, 19 Sep 2011 07:24:07 -0400

> Date: Mon, 19 Sep 2011 12:49:09 +0200
> From: Dani Moncayo <dmoncayo <at> gmail.com>
> Cc: juri <at> jurta.org, 9528 <at> 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.

Message #41 received at 9528 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juri Linkov <juri <at> jurta.org>
Cc: 9528 <at> debbugs.gnu.org, dmoncayo <at> gmail.com
Subject: Re: bug#9528: 24.0.50; Info navigation
Date: Mon, 19 Sep 2011 07:25:36 -0400

> From: Juri Linkov <juri <at> jurta.org>
> Cc: Dani Moncayo <dmoncayo <at> gmail.com>,  9528 <at> 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.

Message #44 received at 9528 <at> debbugs.gnu.org (full text, mbox):

From: Dani Moncayo <dmoncayo <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: juri <at> jurta.org, 9528 <at> debbugs.gnu.org
Subject: Re: bug#9528: 24.0.50; Info navigation
Date: Mon, 19 Sep 2011 14:14:26 +0200

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

Message #47 received at 9528 <at> debbugs.gnu.org (full text, mbox):

From: Dani Moncayo <dmoncayo <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Juri Linkov <juri <at> jurta.org>, 9528 <at> debbugs.gnu.org
Subject: Re: bug#9528: 24.0.50; Info navigation
Date: Mon, 19 Sep 2011 14:45:39 +0200

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

Message #50 received at 9528 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dani Moncayo <dmoncayo <at> gmail.com>
Cc: juri <at> jurta.org, 9528 <at> debbugs.gnu.org
Subject: Re: bug#9528: 24.0.50; Info navigation
Date: Mon, 19 Sep 2011 08:49:38 -0400

> Date: Mon, 19 Sep 2011 14:14:26 +0200
> From: Dani Moncayo <dmoncayo <at> gmail.com>
> Cc: juri <at> jurta.org, 9528 <at> 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.

Message #53 received at 9528 <at> debbugs.gnu.org (full text, mbox):

From: Dani Moncayo <dmoncayo <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: juri <at> jurta.org, 9528 <at> debbugs.gnu.org
Subject: Re: bug#9528: 24.0.50; Info navigation
Date: Mon, 19 Sep 2011 15:04:42 +0200

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

Message #56 received at 9528 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 9528 <at> debbugs.gnu.org, Dani Moncayo <dmoncayo <at> gmail.com>
Subject: Re: bug#9528: 24.0.50; Info navigation
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'.
And Emacs (and I think UIs in general) likes "superficial".


        Stefan

Message #59 received at 9528 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> jurta.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 9528 <at> debbugs.gnu.org, dmoncayo <at> gmail.com
Subject: Re: bug#9528: 24.0.50; Info navigation
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?

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

Message #62 received at 9528 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 9528 <at> debbugs.gnu.org, dmoncayo <at> gmail.com
Subject: Re: bug#9528: 24.0.50; Info navigation
Date: Mon, 19 Sep 2011 19:03:48 +0300

> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: Dani Moncayo <dmoncayo <at> gmail.com>,  9528 <at> 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.

Message #65 received at 9528 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juri Linkov <juri <at> jurta.org>
Cc: 9528 <at> debbugs.gnu.org, dmoncayo <at> gmail.com
Subject: Re: bug#9528: 24.0.50; Info navigation
Date: Mon, 19 Sep 2011 19:06:45 +0300

> From: Juri Linkov <juri <at> jurta.org>
> Cc: dmoncayo <at> gmail.com,  9528 <at> 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.

Message #68 received at 9528 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 9528 <at> debbugs.gnu.org, dmoncayo <at> gmail.com
Subject: Re: bug#9528: 24.0.50; Info navigation
Date: Mon, 19 Sep 2011 12:41:18 -0400

> 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

Message #71 received at 9528 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 9528 <at> debbugs.gnu.org, dmoncayo <at> gmail.com
Subject: Re: bug#9528: 24.0.50; Info navigation
Date: Mon, 19 Sep 2011 19:52:54 +0300

> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: dmoncayo <at> gmail.com,  9528 <at> 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.

Message #74 received at 9528 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> jurta.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, 9528 <at> debbugs.gnu.org
Subject: Re: bug#9528: 24.0.50; Info navigation
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'?

Message #77 received at 9528 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juri Linkov <juri <at> jurta.org>
Cc: monnier <at> iro.umontreal.ca, 9528 <at> debbugs.gnu.org
Subject: Re: bug#9528: 24.0.50; Info navigation
Date: Mon, 19 Sep 2011 22:57:32 +0300

> From: Juri Linkov <juri <at> jurta.org>
> Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>,  9528 <at> 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.

Message #80 received at 9528 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> jurta.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 9528 <at> debbugs.gnu.org, dmoncayo <at> gmail.com
Subject: Re: bug#9528: 24.0.50; Info navigation
Date: Tue, 20 Sep 2011 19:28:52 +0300

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

Message #83 received at 9528 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> jurta.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: monnier <at> iro.umontreal.ca, 9528 <at> debbugs.gnu.org
Subject: Re: bug#9528: 24.0.50; Info navigation
Date: Tue, 20 Sep 2011 19:30:01 +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.

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

Message #86 received at 9528 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juri Linkov <juri <at> jurta.org>
Cc: monnier <at> iro.umontreal.ca, 9528 <at> debbugs.gnu.org
Subject: Re: bug#9528: 24.0.50; Info navigation
Date: Tue, 20 Sep 2011 20:30:06 +0300

> From: Juri Linkov <juri <at> jurta.org>
> Cc: monnier <at> iro.umontreal.ca,  9528 <at> 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.

Message #89 received at 9528 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> jurta.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: monnier <at> iro.umontreal.ca, 9528 <at> debbugs.gnu.org
Subject: Re: bug#9528: 24.0.50; Info navigation
Date: Tue, 20 Sep 2011 20:50:45 +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?

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.

Message #92 received at 9528 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juri Linkov <juri <at> jurta.org>
Cc: monnier <at> iro.umontreal.ca, 9528 <at> debbugs.gnu.org
Subject: Re: bug#9528: 24.0.50; Info navigation
Date: Tue, 20 Sep 2011 22:24:56 +0300

> From: Juri Linkov <juri <at> jurta.org>
> Cc: monnier <at> iro.umontreal.ca,  9528 <at> 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.

Message #97 received at 9528-done <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> jurta.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 9528-done <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
Subject: Re: bug#9528: 24.0.50; Info navigation
Date: Tue, 20 Sep 2011 23:17:19 +0300

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

Installed and closed.

Message #98 received at 9528-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juri Linkov <juri <at> jurta.org>
Cc: 9528-done <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
Subject: Re: bug#9528: 24.0.50; Info navigation
Date: Wed, 21 Sep 2011 00:13:27 -0400

> From: Juri Linkov <juri <at> jurta.org>
> Cc: monnier <at> iro.umontreal.ca,  9528-done <at> debbugs.gnu.org
> Date: Tue, 20 Sep 2011 23:17:19 +0300
> 
> > Then I think that both behaviors should be controlled by the same
> > option, like in the change you suggested.
> >
> > Thanks.
> 
> Installed and closed.

Thank you.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.