* bug#9528: 24.0.50; Info navigation
@ 2011-09-17 10:54 Dani Moncayo
2011-09-17 11:01 ` Dani Moncayo
` (2 more replies)
0 siblings, 3 replies; 31+ messages in thread
From: Dani Moncayo @ 2011-09-17 10:54 UTC (permalink / raw)
To: 9528
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
^ permalink raw reply [flat|nested] 31+ messages in thread* bug#9528: 24.0.50; Info navigation 2011-09-17 10:54 bug#9528: 24.0.50; Info navigation Dani Moncayo @ 2011-09-17 11:01 ` Dani Moncayo 2011-09-17 18:02 ` Juri Linkov 2011-09-17 18:00 ` Juri Linkov 2011-09-18 20:14 ` Juri Linkov 2 siblings, 1 reply; 31+ messages in thread From: Dani Moncayo @ 2011-09-17 11:01 UTC (permalink / raw) To: 9528 > 2. Move point to line 22 (* Simple Macro). ^^ Actually, that line is the 23rd. Sorry. -- Dani Moncayo ^ permalink raw reply [flat|nested] 31+ messages in thread
* bug#9528: 24.0.50; Info navigation 2011-09-17 11:01 ` Dani Moncayo @ 2011-09-17 18:02 ` Juri Linkov 0 siblings, 0 replies; 31+ messages in thread From: Juri Linkov @ 2011-09-17 18:02 UTC (permalink / raw) To: Dani Moncayo; +Cc: 9528 >> 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. ^ permalink raw reply [flat|nested] 31+ messages in thread
* bug#9528: 24.0.50; Info navigation 2011-09-17 10:54 bug#9528: 24.0.50; Info navigation Dani Moncayo 2011-09-17 11:01 ` Dani Moncayo @ 2011-09-17 18:00 ` Juri Linkov 2011-09-18 20:14 ` Juri Linkov 2 siblings, 0 replies; 31+ messages in thread From: Juri Linkov @ 2011-09-17 18:00 UTC (permalink / raw) To: Dani Moncayo; +Cc: 9528 > 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. ^ permalink raw reply [flat|nested] 31+ messages in thread
* bug#9528: 24.0.50; Info navigation 2011-09-17 10:54 bug#9528: 24.0.50; Info navigation Dani Moncayo 2011-09-17 11:01 ` Dani Moncayo 2011-09-17 18:00 ` Juri Linkov @ 2011-09-18 20:14 ` Juri Linkov 2011-09-19 8:14 ` Dani Moncayo 2 siblings, 1 reply; 31+ messages in thread From: Juri Linkov @ 2011-09-18 20:14 UTC (permalink / raw) To: Dani Moncayo; +Cc: 9528 > 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 ?). ^ permalink raw reply [flat|nested] 31+ messages in thread
* bug#9528: 24.0.50; Info navigation 2011-09-18 20:14 ` Juri Linkov @ 2011-09-19 8:14 ` Dani Moncayo 2011-09-19 9:49 ` Eli Zaretskii 0 siblings, 1 reply; 31+ messages in thread From: Dani Moncayo @ 2011-09-19 8:14 UTC (permalink / raw) To: Juri Linkov; +Cc: 9528 >> ------------------------------------------------ >> 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* bug#9528: 24.0.50; Info navigation 2011-09-19 8:14 ` Dani Moncayo @ 2011-09-19 9:49 ` Eli Zaretskii 2011-09-19 10:20 ` Dani Moncayo 2011-09-19 11:16 ` Juri Linkov 0 siblings, 2 replies; 31+ messages in thread From: Eli Zaretskii @ 2011-09-19 9:49 UTC (permalink / raw) To: Dani Moncayo; +Cc: 9528 > 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. ^ permalink raw reply [flat|nested] 31+ messages in thread
* bug#9528: 24.0.50; Info navigation 2011-09-19 9:49 ` Eli Zaretskii @ 2011-09-19 10:20 ` Dani Moncayo 2011-09-19 10:37 ` Eli Zaretskii 2011-09-19 11:16 ` Juri Linkov 1 sibling, 1 reply; 31+ messages in thread From: Dani Moncayo @ 2011-09-19 10:20 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 9528 >> >> ------------------------------------------------ >> >> 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* bug#9528: 24.0.50; Info navigation 2011-09-19 10:20 ` Dani Moncayo @ 2011-09-19 10:37 ` Eli Zaretskii 2011-09-19 10:49 ` Dani Moncayo 0 siblings, 1 reply; 31+ messages in thread From: Eli Zaretskii @ 2011-09-19 10:37 UTC (permalink / raw) To: Dani Moncayo; +Cc: 9528 > 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. ^ permalink raw reply [flat|nested] 31+ messages in thread
* bug#9528: 24.0.50; Info navigation 2011-09-19 10:37 ` Eli Zaretskii @ 2011-09-19 10:49 ` Dani Moncayo 2011-09-19 11:24 ` Eli Zaretskii 0 siblings, 1 reply; 31+ messages in thread From: Dani Moncayo @ 2011-09-19 10:49 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 9528 > 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* bug#9528: 24.0.50; Info navigation 2011-09-19 10:49 ` Dani Moncayo @ 2011-09-19 11:24 ` Eli Zaretskii 2011-09-19 12:14 ` Dani Moncayo 0 siblings, 1 reply; 31+ messages in thread From: Eli Zaretskii @ 2011-09-19 11:24 UTC (permalink / raw) To: Dani Moncayo; +Cc: 9528 > 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. ^ permalink raw reply [flat|nested] 31+ messages in thread
* bug#9528: 24.0.50; Info navigation 2011-09-19 11:24 ` Eli Zaretskii @ 2011-09-19 12:14 ` Dani Moncayo 2011-09-19 12:49 ` Eli Zaretskii 0 siblings, 1 reply; 31+ messages in thread From: Dani Moncayo @ 2011-09-19 12:14 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 9528 >> > 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* bug#9528: 24.0.50; Info navigation 2011-09-19 12:14 ` Dani Moncayo @ 2011-09-19 12:49 ` Eli Zaretskii 2011-09-19 13:04 ` Dani Moncayo 2011-09-19 14:24 ` Stefan Monnier 0 siblings, 2 replies; 31+ messages in thread From: Eli Zaretskii @ 2011-09-19 12:49 UTC (permalink / raw) To: Dani Moncayo; +Cc: 9528 > 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. ^ permalink raw reply [flat|nested] 31+ messages in thread
* bug#9528: 24.0.50; Info navigation 2011-09-19 12:49 ` Eli Zaretskii @ 2011-09-19 13:04 ` Dani Moncayo 2011-09-19 14:24 ` Stefan Monnier 1 sibling, 0 replies; 31+ messages in thread From: Dani Moncayo @ 2011-09-19 13:04 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 9528 >> >> 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* bug#9528: 24.0.50; Info navigation 2011-09-19 12:49 ` Eli Zaretskii 2011-09-19 13:04 ` Dani Moncayo @ 2011-09-19 14:24 ` Stefan Monnier 2011-09-19 16:03 ` Eli Zaretskii 1 sibling, 1 reply; 31+ messages in thread From: Stefan Monnier @ 2011-09-19 14:24 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 9528 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* bug#9528: 24.0.50; Info navigation 2011-09-19 14:24 ` Stefan Monnier @ 2011-09-19 16:03 ` Eli Zaretskii 2011-09-19 16:41 ` Stefan Monnier 0 siblings, 1 reply; 31+ messages in thread From: Eli Zaretskii @ 2011-09-19 16:03 UTC (permalink / raw) To: Stefan Monnier; +Cc: 9528 > 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. ^ permalink raw reply [flat|nested] 31+ messages in thread
* bug#9528: 24.0.50; Info navigation 2011-09-19 16:03 ` Eli Zaretskii @ 2011-09-19 16:41 ` Stefan Monnier 2011-09-19 16:52 ` Eli Zaretskii 0 siblings, 1 reply; 31+ messages in thread From: Stefan Monnier @ 2011-09-19 16:41 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 9528 > 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* bug#9528: 24.0.50; Info navigation 2011-09-19 16:41 ` Stefan Monnier @ 2011-09-19 16:52 ` Eli Zaretskii 2011-09-19 18:49 ` Juri Linkov 0 siblings, 1 reply; 31+ messages in thread From: Eli Zaretskii @ 2011-09-19 16:52 UTC (permalink / raw) To: Stefan Monnier; +Cc: 9528 > 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. ^ permalink raw reply [flat|nested] 31+ messages in thread
* bug#9528: 24.0.50; Info navigation 2011-09-19 16:52 ` Eli Zaretskii @ 2011-09-19 18:49 ` Juri Linkov 2011-09-19 19:57 ` Eli Zaretskii 0 siblings, 1 reply; 31+ messages in thread From: Juri Linkov @ 2011-09-19 18:49 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 9528 >> 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'? ^ permalink raw reply [flat|nested] 31+ messages in thread
* bug#9528: 24.0.50; Info navigation 2011-09-19 18:49 ` Juri Linkov @ 2011-09-19 19:57 ` Eli Zaretskii 2011-09-20 16:30 ` Juri Linkov 0 siblings, 1 reply; 31+ messages in thread From: Eli Zaretskii @ 2011-09-19 19:57 UTC (permalink / raw) To: Juri Linkov; +Cc: 9528 > 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. ^ permalink raw reply [flat|nested] 31+ messages in thread
* bug#9528: 24.0.50; Info navigation 2011-09-19 19:57 ` Eli Zaretskii @ 2011-09-20 16:30 ` Juri Linkov 2011-09-20 17:30 ` Eli Zaretskii 0 siblings, 1 reply; 31+ messages in thread From: Juri Linkov @ 2011-09-20 16:30 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 9528 >> >> 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)) ^ permalink raw reply [flat|nested] 31+ messages in thread
* bug#9528: 24.0.50; Info navigation 2011-09-20 16:30 ` Juri Linkov @ 2011-09-20 17:30 ` Eli Zaretskii 2011-09-20 17:50 ` Juri Linkov 0 siblings, 1 reply; 31+ messages in thread From: Eli Zaretskii @ 2011-09-20 17:30 UTC (permalink / raw) To: Juri Linkov; +Cc: 9528 > 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. ^ permalink raw reply [flat|nested] 31+ messages in thread
* bug#9528: 24.0.50; Info navigation 2011-09-20 17:30 ` Eli Zaretskii @ 2011-09-20 17:50 ` Juri Linkov 2011-09-20 19:24 ` Eli Zaretskii 0 siblings, 1 reply; 31+ messages in thread From: Juri Linkov @ 2011-09-20 17:50 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 9528 >> 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. ^ permalink raw reply [flat|nested] 31+ messages in thread
* bug#9528: 24.0.50; Info navigation 2011-09-20 17:50 ` Juri Linkov @ 2011-09-20 19:24 ` Eli Zaretskii 2011-09-20 20:17 ` Juri Linkov 0 siblings, 1 reply; 31+ messages in thread From: Eli Zaretskii @ 2011-09-20 19:24 UTC (permalink / raw) To: Juri Linkov; +Cc: 9528 > 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. ^ permalink raw reply [flat|nested] 31+ messages in thread
* bug#9528: 24.0.50; Info navigation 2011-09-20 19:24 ` Eli Zaretskii @ 2011-09-20 20:17 ` Juri Linkov 0 siblings, 0 replies; 31+ messages in thread From: Juri Linkov @ 2011-09-20 20:17 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 9528-done > Then I think that both behaviors should be controlled by the same > option, like in the change you suggested. > > Thanks. Installed and closed. ^ permalink raw reply [flat|nested] 31+ messages in thread
* bug#9528: 24.0.50; Info navigation 2011-09-19 9:49 ` Eli Zaretskii 2011-09-19 10:20 ` Dani Moncayo @ 2011-09-19 11:16 ` Juri Linkov 2011-09-19 11:25 ` Eli Zaretskii 1 sibling, 1 reply; 31+ messages in thread From: Juri Linkov @ 2011-09-19 11:16 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 9528 > 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? ^ permalink raw reply [flat|nested] 31+ messages in thread
* bug#9528: 24.0.50; Info navigation 2011-09-19 11:16 ` Juri Linkov @ 2011-09-19 11:25 ` Eli Zaretskii 2011-09-19 12:45 ` Dani Moncayo ` (2 more replies) 0 siblings, 3 replies; 31+ messages in thread From: Eli Zaretskii @ 2011-09-19 11:25 UTC (permalink / raw) To: Juri Linkov; +Cc: 9528 > 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. ^ permalink raw reply [flat|nested] 31+ messages in thread
* bug#9528: 24.0.50; Info navigation 2011-09-19 11:25 ` Eli Zaretskii @ 2011-09-19 12:45 ` Dani Moncayo 2011-09-19 14:23 ` Juri Linkov 2011-09-20 16:28 ` Juri Linkov 2 siblings, 0 replies; 31+ messages in thread From: Dani Moncayo @ 2011-09-19 12:45 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 9528 >> > 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* bug#9528: 24.0.50; Info navigation 2011-09-19 11:25 ` Eli Zaretskii 2011-09-19 12:45 ` Dani Moncayo @ 2011-09-19 14:23 ` Juri Linkov 2011-09-19 16:06 ` Eli Zaretskii 2011-09-20 16:28 ` Juri Linkov 2 siblings, 1 reply; 31+ messages in thread From: Juri Linkov @ 2011-09-19 14:23 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 9528 >> (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. ^ permalink raw reply [flat|nested] 31+ messages in thread
* bug#9528: 24.0.50; Info navigation 2011-09-19 14:23 ` Juri Linkov @ 2011-09-19 16:06 ` Eli Zaretskii 0 siblings, 0 replies; 31+ messages in thread From: Eli Zaretskii @ 2011-09-19 16:06 UTC (permalink / raw) To: Juri Linkov; +Cc: 9528 > 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. ^ permalink raw reply [flat|nested] 31+ messages in thread
* bug#9528: 24.0.50; Info navigation 2011-09-19 11:25 ` Eli Zaretskii 2011-09-19 12:45 ` Dani Moncayo 2011-09-19 14:23 ` Juri Linkov @ 2011-09-20 16:28 ` Juri Linkov 2 siblings, 0 replies; 31+ messages in thread From: Juri Linkov @ 2011-09-20 16:28 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 9528 >> >> >> 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. ^ permalink raw reply [flat|nested] 31+ messages in thread
end of thread, other threads:[~2011-09-20 20:17 UTC | newest] Thread overview: 31+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2011-09-17 10:54 bug#9528: 24.0.50; Info navigation Dani Moncayo 2011-09-17 11:01 ` Dani Moncayo 2011-09-17 18:02 ` Juri Linkov 2011-09-17 18:00 ` Juri Linkov 2011-09-18 20:14 ` Juri Linkov 2011-09-19 8:14 ` Dani Moncayo 2011-09-19 9:49 ` Eli Zaretskii 2011-09-19 10:20 ` Dani Moncayo 2011-09-19 10:37 ` Eli Zaretskii 2011-09-19 10:49 ` Dani Moncayo 2011-09-19 11:24 ` Eli Zaretskii 2011-09-19 12:14 ` Dani Moncayo 2011-09-19 12:49 ` Eli Zaretskii 2011-09-19 13:04 ` Dani Moncayo 2011-09-19 14:24 ` Stefan Monnier 2011-09-19 16:03 ` Eli Zaretskii 2011-09-19 16:41 ` Stefan Monnier 2011-09-19 16:52 ` Eli Zaretskii 2011-09-19 18:49 ` Juri Linkov 2011-09-19 19:57 ` Eli Zaretskii 2011-09-20 16:30 ` Juri Linkov 2011-09-20 17:30 ` Eli Zaretskii 2011-09-20 17:50 ` Juri Linkov 2011-09-20 19:24 ` Eli Zaretskii 2011-09-20 20:17 ` Juri Linkov 2011-09-19 11:16 ` Juri Linkov 2011-09-19 11:25 ` Eli Zaretskii 2011-09-19 12:45 ` Dani Moncayo 2011-09-19 14:23 ` Juri Linkov 2011-09-19 16:06 ` Eli Zaretskii 2011-09-20 16:28 ` Juri Linkov
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).