[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[O] Inconsistent behavior in generating file link search strings
From: |
Matt Lundin |
Subject: |
[O] Inconsistent behavior in generating file link search strings |
Date: |
Sun, 26 Mar 2017 12:21:32 -0500 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) |
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
- [O] Inconsistent behavior in generating file link search strings,
Matt Lundin <=