Re: Inconsistent behavior in generating file link search strings

[Matt Lundin <mdl@imapmail.org>]

Matt Lundin <mdl@imapmail.org> writes:

> 1. First, org-insert-link truncates the search string. Here are the
> steps to reproduce with emacs -Q:
>
>  - Store a link in a plain text file. The value of org-stored-links is:
>
>     org-stored-links is a variable defined in ‘org.el’.
>     Its value is
>
>     (("file:~/test.txt::Duis aute irure dolor in\nreprehenderit in voluptate velit esse cillum dolore eu fugiat nulla\npariatur." nil))
>
>  - Insert the link in an org buffer using org-insert-link. The resulting
>    link looks like this:
>
>    [[file:~/test.txt::Duis%20aute%20irure%20dolor%20in]]
>
>  - This seems to run counter to the advertised behavior in
>    org-context-in-file-links, which says the entire region will be
>    stored by default.
>
>  - The problem is the regex on line 10333 or org.el:
>
>          (string-match "^file:\\(.+?\\)::\\(.+\\)" link))

It turns out that the line I mentioned above is actually relevant only
in some cases, as it applies only when linking to an item in the current
file. 

The regex that cause the problem in most cases is line 10343:

    (when (string-match "^\\(file:\\|docview:\\)\\(.*\\)" link)

In this case, insert link will also fail if the filename happens to
contain a new line (a corner-case, I admit!).

Matt