bug#20090: 24.4: linking to a position within an info node

bug#20090: 24.4: linking to a position within an info node

[Boruch Baum]

[-- Attachment #1: Type: text/plain, Size: 508 bytes --]

When the org mode manual discusses creating links, it gives an example
of linking to an info node (the self-referencing example is
`info:org#External' links). The manual continues, at node
`info:org#Search options', to describe how specific positions within
file links can be directly specified. This does work for links to
regular files, but does not work for positions within an info node (eg.
line 85 of node x).

-- 
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

bug#20090: 24.4: linking to a position within an info node

[Juri Linkov]

> When the org mode manual discusses creating links, it gives an example
> of linking to an info node (the self-referencing example is
> `info:org#External' links). The manual continues, at node
> `info:org#Search options', to describe how specific positions within
> file links can be directly specified. This does work for links to
> regular files, but does not work for positions within an info node (eg.
> line 85 of node x).

Is there an official format for the line numbers in Info cross-references?

(info "(texinfo) Printing Indices & Menus") documents the format of
line numbers only in the index, not in the cross-references:

   * In Info output, `@printindex' produces a special menu containing
     the line number of the entry, relative to the start of the node.
     Info readers can use this to go to the exact line of an entry, not
     just the containing node.  (Older Info readers will just go to the
     node.)  Here's an example:

          * First index entry:   Top.   (line  7)

     The actual number of spaces is variable, to right-justify the line
     number; it's been reduced here to make the line fit in the printed
     manual.

The Info reader already supports this format in the index.

bug#20090: 24.4: linking to a position within an info node

[Boruch Baum]

[-- Attachment #1: Type: text/plain, Size: 2978 bytes --]

On 03/12/2015 03:50 PM, Juri Linkov wrote:
>> When the org mode manual discusses creating links, it gives an example
>> of linking to an info node (the self-referencing example is
>> `info:org#External' links). The manual continues, at node
>> `info:org#Search options', to describe how specific positions within
>> file links can be directly specified. This does work for links to
>> regular files, but does not work for positions within an info node (eg.
>> line 85 of node x).
> 
> Is there an official format for the line numbers in Info cross-references?
I don't know - my assumption was that within emacs, it would be
basically just another type of emacs buffer, and be a legitimate subject
for all elisp commands.

Your question got me thinking, that emacs may have subtle rendering
quirks, so just now, I opened fresh instances of info buffers in both
very wide and very narrow windows, and they both `fill' to the same line
length, ie the wide window has a lot of right-side white-space, and the
narrow window has lines wrapped.

Since I submitted the bug report, I've continued trying to get the
feature working, and have been experimenting with the org-mode hooks
`org-create-file-search-functions' and
`org-execute-file-search-functions' to no success. The only, supposedly
working examples I've come across for these functions are [1] and [2].
If you know of other resources, that could be helpful.

One other possible related bug I've found is that when trying to use
org-store-link for a particular line number within an org-file, the link
is created to the most recent header. One can successfully, manually,
hack the created link, replacing the reference to the header with a line
number, in order to be able to navigate directly to the desired line
(all this, for a link target in an org mode file - this was done as a
test, once I came across the original bug) [3].

[1]
https://stackoverflow.com/questions/10681766/emacs-org-mode-textual-reference-to-a-fileline

[2] http://www.emacswiki.org/emacs/.emacs-DominiqueQuatravaux.el

[3] info:org#Search options

> 
> (info "(texinfo) Printing Indices & Menus") documents the format of
> line numbers only in the index, not in the cross-references:
> 
>    * In Info output, `@printindex' produces a special menu containing
>      the line number of the entry, relative to the start of the node.
>      Info readers can use this to go to the exact line of an entry, not
>      just the containing node.  (Older Info readers will just go to the
>      node.)  Here's an example:
> 
>           * First index entry:   Top.   (line  7)
> 
>      The actual number of spaces is variable, to right-justify the line
>      number; it's been reduced here to make the line fit in the printed
>      manual.
> 
> The Info reader already supports this format in the index.
> 


-- 
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

bug#20090: 24.4: linking to a position within an info node

[Nicolas Goaziou]

Hello,

Boruch Baum <boruch_baum@gmx.com> writes:

> On 03/12/2015 03:50 PM, Juri Linkov wrote:
>>> When the org mode manual discusses creating links, it gives an example
>>> of linking to an info node (the self-referencing example is
>>> `info:org#External' links). The manual continues, at node
>>> `info:org#Search options', to describe how specific positions within
>>> file links can be directly specified. This does work for links to
>>> regular files, but does not work for positions within an info node (eg.
>>> line 85 of node x).
>> 
>> Is there an official format for the line numbers in Info cross-references?
> I don't know - my assumption was that within emacs, it would be
> basically just another type of emacs buffer, and be a legitimate subject
> for all elisp commands.
>
> Your question got me thinking, that emacs may have subtle rendering
> quirks, so just now, I opened fresh instances of info buffers in both
> very wide and very narrow windows, and they both `fill' to the same line
> length, ie the wide window has a lot of right-side white-space, and the
> narrow window has lines wrapped.
>
> Since I submitted the bug report, I've continued trying to get the
> feature working, and have been experimenting with the org-mode hooks
> `org-create-file-search-functions' and
> `org-execute-file-search-functions' to no success. The only, supposedly
> working examples I've come across for these functions are [1] and [2].
> If you know of other resources, that could be helpful.

Info links are also meant to be exported. Linking to a line number
doesn't sound portable. I don't think it should be supported out of the
box.

In any case, you can implement your own link types, if you need this
specific feature. See `org-link-parameters' for details.

> One other possible related bug I've found is that when trying to use
> org-store-link for a particular line number within an org-file, the link
> is created to the most recent header. One can successfully, manually,
> hack the created link, replacing the reference to the header with a line
> number, in order to be able to navigate directly to the desired line
> (all this, for a link target in an org mode file - this was done as a
> test, once I came across the original bug) [3].

Please open a new bug report if you think you found a bug. I'm closing
this one.

Thank you!

Regards,

-- 
Nicolas Goaziou                                                0x80A93738

bug#20090: 24.4: linking to a position within an info node

[Nicolas Goaziou]

Closing the bug report.

bug#20090: improperly closed

[Boruch Baum]

Bug report 20090 was perfunctorily closed today:

1] without the person who performed the action consulting with the bug
reporter;

2] without any discussion for over 2.5 years;

3] with a reason given that demonstrates that the person who performed
the action didn't give the action much of any thought;

In this particular case, the person who closed the bug apparently looked
at the sentence fragment 'does not work for positions within an info node (eg.
 line 85 of node x)', and confused the term `eg' with the term 'ie'.

At this point, emacs is uniquely inferior to all major 'word processors'
in that it does not support the feature described in the bug, ie. the
ability to link to a specific position within a document.

Pretty basic, no?

-- 
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

bug#20090: improperly closed

[Nicolas Goaziou]

Boruch Baum <boruch_baum@gmx.com> writes:

> Bug report 20090 was perfunctorily closed today:

> 1] without the person who performed the action consulting with the bug
> reporter;

You're free to re-open the bug or create another one if you disagree.
For the record, I don't consider this to be a bug, but a feature
request.

> 2] without any discussion for over 2.5 years;

I hope you are not blaming me for that.

> 3] with a reason given that demonstrates that the person who performed
> the action didn't give the action much of any thought;

Yet, I gave it more thought than anyone in 2.5 years!

> In this particular case, the person who closed the bug apparently looked
> at the sentence fragment 'does not work for positions within an info node (eg.
>  line 85 of node x)', and confused the term `eg' with the term 'ie'.

How nice.

> At this point, emacs is uniquely inferior to all major 'word processors'
> in that it does not support the feature described in the bug, ie. the
> ability to link to a specific position within a document.
>
> Pretty basic, no?

Pretty inaccurate, actually. Org is able to link to a specific position
within an Org document, and to a specific line in any plain text
document.

Your feature request is to link to a specific position in a document
written in a foreign, processed format, namely Info. I cannot think of
any reliable way to do so (e.g., "going to the node, and searching for
a string" doesn't qualify as "reliable"). If you have an idea about it,
I suggest to first implement it as a custom link type, and open a proper
feature request, or report it on the Org mailing list.

Another option is to wait for 2.5 years again and despise the next
person to close this report.

Regards,