From mboxrd@z Thu Jan 1 00:00:00 1970 From: Matt Lundin Subject: Inconsistent behavior in generating file link search strings Date: Sun, 26 Mar 2017 12:21:32 -0500 Message-ID: <87h92gx9ak.fsf@fastmail.fm> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:56923) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1csBrL-0001Fi-0k for emacs-orgmode@gnu.org; Sun, 26 Mar 2017 13:21:43 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1csBrG-0000y4-3x for emacs-orgmode@gnu.org; Sun, 26 Mar 2017 13:21:43 -0400 Received: from out1-smtp.messagingengine.com ([66.111.4.25]:58981) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1csBrF-0000xn-Jb for emacs-orgmode@gnu.org; Sun, 26 Mar 2017 13:21:38 -0400 Received: from archpad (c-24-14-63-242.hsd1.il.comcast.net [24.14.63.242]) by mail.messagingengine.com (Postfix) with ESMTPA id 7BC7C240B3 for ; Sun, 26 Mar 2017 13:21:33 -0400 (EDT) List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: "Emacs-orgmode" To: Org Mode 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.=20 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 =E2=80=98org.el=E2=80=99. Its value is (("file:~/test.txt::Duis aute irure dolor in\nreprehenderit in voluptat= e 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: =20=20=20 (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%0Areprehenderi= t%20in%20voluptate%20velit%20esse%20cillum%20dolore%20eu%20fugiat%20nulla%0= Apariatur.]] =20=20 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