From: Matt Lundin <mdl@imapmail.org>
To: Org Mode <emacs-orgmode@gnu.org>
Subject: Inconsistent behavior in generating file link search strings
Date: Sun, 26 Mar 2017 12:21:32 -0500 [thread overview]
Message-ID: <87h92gx9ak.fsf@fastmail.fm> (raw)
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
next reply other threads:[~2017-03-26 17:21 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-26 17:21 Matt Lundin [this message]
2017-03-27 15:01 ` Inconsistent behavior in generating file link search strings Matt Lundin
2017-03-27 15:02 ` [PATCH] Allow insertion of links with multi-line " Matt Lundin
2017-03-29 13:38 ` Nicolas Goaziou
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87h92gx9ak.fsf@fastmail.fm \
--to=mdl@imapmail.org \
--cc=emacs-orgmode@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).