Inconsistent behavior in generating file link search strings

Inconsistent behavior in generating file link search strings

[Matt Lundin]

I am grabbing a lot of links from plain text files these days and find
that the way in which org generates search strings in file links is
inconsistent. That is, org-capture and org-insert-link behave
differently. 

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

2. By contrast, the annotation substitution (%a) in org-capture inserts
the whole search string:

  - Take the following capture template:
   
      (setq org-capture-templates
            '(("n" "Note" entry
	           (file "~/config/test.org")
                   "* Test\n %a\n")))

  - Select the same region in a dummy file as a above and call
    org-capture, using the "n" template.

  - The org-capture snippet contains the whole search string, including
    new lines:

        * Test
         [[file:~/test.txt::Duis%20aute%20irure%20dolor%20in%0Areprehenderit%20in%20voluptate%20velit%20esse%20cillum%20dolore%20eu%20fugiat%20nulla%0Apariatur.]]
  
I think org-capture (#2) is in keeping with the behavior advertised by
org-context-in-file-links. However, as I will explain in a subsequent
bug report, org-link-search currently fails if the search string
contains new lines, so, in fact, only the one-line search strings
generated by org-insert-link actually work when following links.

Matt

Re: Inconsistent behavior in generating file link search strings

[Matt Lundin]

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

[PATCH] Allow insertion of links with multi-line search strings

[Matt Lundin]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: 0001-Allow-insertion-of-links-with-multi-line-search-stri.patch --]
[-- Type: text/x-diff, Size: 1407 bytes --]

From 726eba76f31537747a26a7689ee632ec8e9bc01f Mon Sep 17 00:00:00 2001
From: Matt Lundin <mdl@imapmail.org>
Date: Mon, 27 Mar 2017 09:55:33 -0500
Subject: [PATCH] Allow insertion of links with multi-line search strings

* lisp/org.el: (org-insert-link): Fix regexps to match across
  newlines.
---
 lisp/org.el | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/lisp/org.el b/lisp/org.el
index e40db18f6..dcfa4fd6f 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -10330,7 +10330,7 @@ Use TAB to complete link prefixes, then RET for type-specific completion support
     ;; option If yes, simplify the link by using only the search
     ;; option.
     (when (and buffer-file-name
-	       (string-match "^file:\\(.+?\\)::\\(.+\\)" link))
+	       (string-match "^file:\\(.+?\\)::\\(\\(.\\|\n\\)+\\)" link))
       (let* ((path (match-string 1 link))
 	     (case-fold-search nil)
 	     (search (match-string 2 link)))
@@ -10340,7 +10340,7 @@ Use TAB to complete link prefixes, then RET for type-specific completion support
 	    (setq link search)))))
 
     ;; Check if we can/should use a relative path.  If yes, simplify the link
-    (when (string-match "^\\(file:\\|docview:\\)\\(.*\\)" link)
+    (when (string-match "^\\(file:\\|docview:\\)\\(\\(.\\|\n\\)*\\)" link)
       (let* ((type (match-string 1 link))
 	     (path (match-string 2 link))
 	     (origpath path)
-- 
2.12.1

Re: [PATCH] Allow insertion of links with multi-line search strings

[Nicolas Goaziou]

Hello,

Matt Lundin <mdl@imapmail.org> writes:

> From 726eba76f31537747a26a7689ee632ec8e9bc01f Mon Sep 17 00:00:00 2001
> From: Matt Lundin <mdl@imapmail.org>
> Date: Mon, 27 Mar 2017 09:55:33 -0500
> Subject: [PATCH] Allow insertion of links with multi-line search strings
>
> * lisp/org.el: (org-insert-link): Fix regexps to match across
>   newlines.
> ---
>  lisp/org.el | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/lisp/org.el b/lisp/org.el
> index e40db18f6..dcfa4fd6f 100644
> --- a/lisp/org.el
> +++ b/lisp/org.el
> @@ -10330,7 +10330,7 @@ Use TAB to complete link prefixes, then RET for type-specific completion support
>      ;; option If yes, simplify the link by using only the search
>      ;; option.
>      (when (and buffer-file-name
> -	       (string-match "^file:\\(.+?\\)::\\(.+\\)" link))
> +	       (string-match "^file:\\(.+?\\)::\\(\\(.\\|\n\\)+\\)" link))
>        (let* ((path (match-string 1 link))
>  	     (case-fold-search nil)
>  	     (search (match-string 2 link)))
> @@ -10340,7 +10340,7 @@ Use TAB to complete link prefixes, then RET for type-specific completion support
>  	    (setq link search)))))
>  
>      ;; Check if we can/should use a relative path.  If yes, simplify the link
> -    (when (string-match "^\\(file:\\|docview:\\)\\(.*\\)" link)
> +    (when (string-match "^\\(file:\\|docview:\\)\\(\\(.\\|\n\\)*\\)"
> link)

Applied. Thank you.

Regards,

-- 
Nicolas Goaziou