GNU bug report logs - #14717
24.3.50; Info-try-follow-nearest-node misses some footnotes

Previous Next

Package: emacs;

Reported by: Stephen Berman <stephen.berman <at> gmx.net>

Date: Tue, 25 Jun 2013 18:36:02 UTC

Severity: normal

Found in version 24.3.50

Done: Stephen Berman <stephen.berman <at> gmx.net>

Bug is archived. No further changes may be made.

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

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

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#14717; Package emacs. (Tue, 25 Jun 2013 18:36:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Stephen Berman <stephen.berman <at> gmx.net>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Tue, 25 Jun 2013 18:36:02 GMT) Full text and rfc822 format available.

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

From: Stephen Berman <stephen.berman <at> gmx.net>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.3.50; Info-try-follow-nearest-node misses some footnotes
Date: Tue, 25 Jun 2013 20:34:53 +0200
0. emacs -Q
1. Type `C-h i m Elisp RET m Using Interactive RET TAB TAB TAB' to put
   point on the left parent of the reference mark for footnote (1) in
   this node.
2. Type RET, expecting to jump to the footnote, but instead:
=> user-error: No such node or anchor: It may be a string; its contents
are a sequence of elements

The reason is that in Info-try-follow-nearest-node the search for a node
name succeeds, so it never gets to the footnote search, but the matching
string is not a node name, so user-error is signalled.  The following
patch makes the footnote search and hence jumping to the footnote in
that node succeed, but I'll defer to the judgment of the Info or regexp
gurus as to whether it's the best fix.

=== modified file 'lisp/info.el'
*** lisp/info.el	2013-05-27 22:42:11 +0000
--- lisp/info.el	2013-06-25 18:24:56 +0000
***************
*** 3870,3892 ****
       ((setq node (Info-get-token (point) "\\*note[ \n\t]+"
  				 "\\*note[ \n\t]+\\([^:]*\\):\\(:\\|[ \n\t]*(\\)?"))
        (Info-follow-reference node fork))
-      ;; menu item: node name
-      ((setq node (Info-get-token (point) "\\* +" "\\* +\\([^:]*\\)::"))
-       (Info-goto-node node fork))
-      ;; menu item: node name or index entry
-      ((Info-get-token (point) "\\* +" "\\* +\\(.*\\): ")
-       (beginning-of-line)
-       (forward-char 2)
-       (setq node (Info-extract-menu-node-name nil (Info-index-node)))
-       (Info-goto-node node fork))
-      ((setq node (Info-get-token (point) "Up: " "Up: \\([^,\n\t]*\\)"))
-       (Info-goto-node node fork))
-      ((setq node (Info-get-token (point) "Next: " "Next: \\([^,\n\t]*\\)"))
-       (Info-goto-node node fork))
-      ((setq node (Info-get-token (point) "File: " "File: \\([^,\n\t]*\\)"))
-       (Info-goto-node "Top" fork))
-      ((setq node (Info-get-token (point) "Prev: " "Prev: \\([^,\n\t]*\\)"))
-       (Info-goto-node node fork))
       ;; footnote
       ((setq node (Info-get-token (point) "(" "\\(([0-9]+)\\)"))
        (let ((old-point (point)) new-point)
--- 3870,3875 ----
***************
*** 3904,3910 ****
  	    (progn
  	      (goto-char new-point)
  	      (setq node t))
! 	  (setq node nil)))))
      node))
  
  (defun Info-mouse-follow-link (click)
--- 3887,3910 ----
  	    (progn
  	      (goto-char new-point)
  	      (setq node t))
! 	  (setq node nil))))
!      ;; menu item: node name
!      ((setq node (Info-get-token (point) "\\* +" "\\* +\\([^:]*\\)::"))
!       (Info-goto-node node fork))
!      ;; menu item: node name or index entry
!      ((Info-get-token (point) "\\* +" "\\* +\\(.*\\): ")
!       (beginning-of-line)
!       (forward-char 2)
!       (setq node (Info-extract-menu-node-name nil (Info-index-node)))
!       (Info-goto-node node fork))
!      ((setq node (Info-get-token (point) "Up: " "Up: \\([^,\n\t]*\\)"))
!       (Info-goto-node node fork))
!      ((setq node (Info-get-token (point) "Next: " "Next: \\([^,\n\t]*\\)"))
!       (Info-goto-node node fork))
!      ((setq node (Info-get-token (point) "File: " "File: \\([^,\n\t]*\\)"))
!       (Info-goto-node "Top" fork))
!      ((setq node (Info-get-token (point) "Prev: " "Prev: \\([^,\n\t]*\\)"))
!       (Info-goto-node node fork)))
      node))
  
  (defun Info-mouse-follow-link (click)


In GNU Emacs 24.3.50.2 (x86_64-suse-linux-gnu, GTK+ Version 3.4.4)
 of 2013-06-25 on rosalinde
Bzr revision: 113175 lekktu <at> gmail.com-20130625172019-xiu7eowuwtknvz39
Windowing system distributor `The X.Org Foundation', version 11.0.11203000
System Description:	openSUSE 12.2 (x86_64)

Configured using:
 `configure --without-toolkit-scroll-bars CFLAGS=-g3 -O0'

Important settings:
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: @im=local
  locale-coding-system: utf-8-unix
  default enable-multibyte-characters: t




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#14717; Package emacs. (Wed, 26 Jun 2013 23:41:01 GMT) Full text and rfc822 format available.

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

From: Juri Linkov <juri <at> jurta.org>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: 14717 <at> debbugs.gnu.org
Subject: Re: bug#14717: 24.3.50;
 Info-try-follow-nearest-node misses some footnotes
Date: Thu, 27 Jun 2013 02:39:07 +0300
> 0. emacs -Q
> 1. Type `C-h i m Elisp RET m Using Interactive RET TAB TAB TAB' to put
>    point on the left parent of the reference mark for footnote (1) in
>    this node.
> 2. Type RET, expecting to jump to the footnote, but instead:
> => user-error: No such node or anchor: It may be a string; its contents
> are a sequence of elements
>
> The following patch makes the footnote search and
> hence jumping to the footnote in that node succeed

Thanks, your patch correctly fixes the bug, I recommend to commit it.

BTW, if you are interested what I'm trying to do in bug#14670
where I renamed the text property of footnotes from `link' to `shr-url'
is to support shr-url links in Info.  The value of the text properly
`shr-url' is the target of the link.  The problem is how to address
a footnote?  Maybe add a function that finds a footnote.  But I'm afraid
that supporting an arbitrary function on the text properly `shr-url'
is too unsafe.  So `shr-url' should contain only a string.  The question
is in what format to specify a link to a footnote.  Currently it has
the value `t'.  Perhaps as a string it could contain a line number
of the footnote like "(elisp) Using Interactive (line 42)".




Reply sent to Stephen Berman <stephen.berman <at> gmx.net>:
You have taken responsibility. (Thu, 27 Jun 2013 09:38:01 GMT) Full text and rfc822 format available.

Notification sent to Stephen Berman <stephen.berman <at> gmx.net>:
bug acknowledged by developer. (Thu, 27 Jun 2013 09:38:02 GMT) Full text and rfc822 format available.

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

From: Stephen Berman <stephen.berman <at> gmx.net>
To: Juri Linkov <juri <at> jurta.org>
Cc: 14717-done <at> debbugs.gnu.org
Subject: Re: bug#14717: 24.3.50;
 Info-try-follow-nearest-node misses some footnotes
Date: Thu, 27 Jun 2013 11:37:16 +0200
On Thu, 27 Jun 2013 02:39:07 +0300 Juri Linkov <juri <at> jurta.org> wrote:

>> 0. emacs -Q
>> 1. Type `C-h i m Elisp RET m Using Interactive RET TAB TAB TAB' to put
>>    point on the left parent of the reference mark for footnote (1) in
>>    this node.
>> 2. Type RET, expecting to jump to the footnote, but instead:
>> => user-error: No such node or anchor: It may be a string; its contents
>> are a sequence of elements
>>
>> The following patch makes the footnote search and
>> hence jumping to the footnote in that node succeed
>
> Thanks, your patch correctly fixes the bug, 

Thanks for confirming.

>                                             I recommend to commit it.

Done and closing the bug.

> BTW, if you are interested what I'm trying to do in bug#14670
> where I renamed the text property of footnotes from `link' to `shr-url'
> is to support shr-url links in Info.  The value of the text properly
> `shr-url' is the target of the link.  The problem is how to address
> a footnote?  Maybe add a function that finds a footnote.  But I'm afraid
> that supporting an arbitrary function on the text properly `shr-url'
> is too unsafe.  So `shr-url' should contain only a string.  The question
> is in what format to specify a link to a footnote.  Currently it has
> the value `t'.  Perhaps as a string it could contain a line number
> of the footnote like "(elisp) Using Interactive (line 42)".

Would that mean the link would have to be manually updated whenever the
line number of the footnote in the file changes?  If so, it seems
error-prone.  But I don't know the implementation, maybe that's not an
issue.  Otherwise, seems like an interesting idea.

Steve Berman




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#14717; Package emacs. (Fri, 28 Jun 2013 22:03:01 GMT) Full text and rfc822 format available.

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

From: Juri Linkov <juri <at> jurta.org>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: 14717 <at> debbugs.gnu.org
Subject: Re: bug#14717: 24.3.50;
 Info-try-follow-nearest-node misses some footnotes
Date: Sat, 29 Jun 2013 00:50:51 +0300
>> BTW, if you are interested what I'm trying to do in bug#14670
>> where I renamed the text property of footnotes from `link' to `shr-url'
>> is to support shr-url links in Info.  The value of the text properly
>> `shr-url' is the target of the link.  The problem is how to address
>> a footnote?  Maybe add a function that finds a footnote.  But I'm afraid
>> that supporting an arbitrary function on the text properly `shr-url'
>> is too unsafe.  So `shr-url' should contain only a string.  The question
>> is in what format to specify a link to a footnote.  Currently it has
>> the value `t'.  Perhaps as a string it could contain a line number
>> of the footnote like "(elisp) Using Interactive (line 42)".
>
> Would that mean the link would have to be manually updated whenever the
> line number of the footnote in the file changes?  If so, it seems
> error-prone.  But I don't know the implementation, maybe that's not an
> issue.  Otherwise, seems like an interesting idea.

`Info-fontify-node' could calculate the line number dynamically
before putting it to the text property `link', but since I have
no idea in what format to put line numbers in links, I'll leave
it unchanged for now.

The main point for bug#14670 is to put a new condition
that checks general links to `Info-try-follow-nearest-node'
either after checking for footnotes, or before checking
for footnotes but with an additional condition

  `(not (eq node t))'

because for footnotes `Info-fontify-node' puts the text property `link'
with the value `t' that should be skipped when the current link
is a link to footnote and not a general link, so another existing
`cond' branch will check whether text at point contains a link for footnote.
I see no problems for footnotes after adding processing of general links
with this patch:

=== modified file 'lisp/info.el'
--- lisp/info.el	2013-06-27 09:20:04 +0000
+++ lisp/info.el	2013-06-27 23:31:27 +0000
@@ -3863,6 +3919,8 @@ (defun Info-try-follow-nearest-node (&op
 If FORK is non-nil, it is passed to `Info-goto-node'."
   (let (node)
     (cond
+     ((and (setq node (get-text-property (point) 'link)) (not (eq node t)))
+      (Info-goto-node node fork))
      ((setq node (Info-get-token (point) "[hf]t?tps?://"
 				 "\\([hf]t?tps?://[^ \t\n\"`({<>})']+\\)"))
       (browse-url node)




bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Sat, 27 Jul 2013 11:24:03 GMT) Full text and rfc822 format available.

This bug report was last modified 10 years and 287 days ago.

Previous Next


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