emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
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

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