From mboxrd@z Thu Jan 1 00:00:00 1970 From: John Hendy Subject: Re: internal links not being followed; instead, offer to create new heading Date: Sun, 10 Feb 2013 16:38:24 -0600 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([208.118.235.92]:48195) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U4fXY-0002KU-NG for emacs-orgmode@gnu.org; Sun, 10 Feb 2013 17:38:30 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1U4fXW-0006cY-3M for emacs-orgmode@gnu.org; Sun, 10 Feb 2013 17:38:28 -0500 Received: from mail-la0-x236.google.com ([2a00:1450:4010:c03::236]:37664) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U4fXV-0006c5-NA for emacs-orgmode@gnu.org; Sun, 10 Feb 2013 17:38:26 -0500 Received: by mail-la0-f54.google.com with SMTP id gw10so5172592lab.41 for ; Sun, 10 Feb 2013 14:38:24 -0800 (PST) In-Reply-To: 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-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Brian van den Broek Cc: emacs-orgmode On Sun, Feb 10, 2013 at 4:28 PM, Brian van den Broek wrote: > On 10 February 2013 16:21, John Hendy wrote: >> On Sun, Feb 10, 2013 at 12:53 PM, Brian van den Broek >> wrote: >>> Hi all, >>> >>> I am having trouble with following internal org links. After carefully >>> reading the documentation (especially 4.2 Internal Links >>> ) with the following >>> test.org file, I would expect that C-c C-o on the link text in the bar >>> tree would jump to the corresponding text in the foo tree. >> >> I'd never heard of being able to do this, so I read the documentation >> as well and this how I parsed it: >> >> - Is link text a URL? >> - If yes -> open url >> - If no, check current file >> >> - Is link text a custom ID? >> - If yes -> go to headline with matching ID >> - If no, check for custom target >> >> - Is there a match between [[link text]] and an occurrence of <> text>> (dedicated target)? >> - If yes -> go to the dedicated target location >> - If no, check file type >> >> - Is this a .org file? >> - If yes, check for a *headline* (or possibly keywords/tags) >> matching the [[link text]] [1] >> - If no, conduct a string search for the [[link text]] >> >> [1] Quote: "If no dedicated target exists, Org will search for a >> headline that is exactly the link text but may also include a TODO >> keyword and tags" > > > >> 1) The documentation is incorrect (maybe), or >> 2) I don't know how to do C-c C-o provided by Org in a non-org file >> correctly (more probable) >> > > > > > Hi John, > > Thanks for the reply. > > This prodded me to investigate more thoroughly (and to learn how to > use git bisect). I had observed that org 6.33 behaved as I expected > from looking at the documentation. > > Bisecting led to: > > commit a84c8a2cba8c510acfa0c14487f6c993f664a406 > Author: Carsten Dominik > Date: Fri Aug 6 08:34:33 2010 +0200 > > Make internal links in Org files search for an exact headline match > > * lisp/org.el (org-link-search-must-match-exact-headline): New option= . > (org-link-search-inhibit-query): New variable. > (org-link-search): Search for exact headline match in Org files > * doc/org.texi (Internal links): Document the changes in internal lin= ks. > > Internal links used to do a fuzzy text search for the link text. Thi= s > patch changes the behavior for Org files. Here a link [[My Target]] > now searches for an exact headline match, i.e. for a headline that > does look like "* My Target", optionally with TODO keyword, priority > cookie and tags. > > The new option `org-link-search-must-match-exact-headline' is > `query-to-create' by default. This means that a failed link search > will offer to create the headline as a top-level headline at the end > of the buffer. This corresponds to a wiki-like behavior where missin= g > targets are automatically created. If you do not like this behavior, > change the option to t. > > > The commit alters the docs, evidently intending them to be read as you > (John) read them. I'd argue that this wasn't entirely pulled off, as > the passage "Links such as =E2=80=98[[My Target]]=E2=80=99 or =E2=80=98[[= My Target][Find my > target]]=E2=80=99 lead to a text search in the current file" combined wit= h my > memory of how org used to work gave me a different expectation. > Nice digging! I saw that as well... one interpretation could be that it should fall back to a full text search of the document. Another interpretation is that if it's not a URL it falls back to a "text search" in which "text" =3D a unique ID, dedicated <> or headline. Definitely not clear, though. > At any rate, to my cursory testing, > > (setq org-link-search-must-match-exact-headline nil) > > in my .emacs appears to make org behave as I expect it to. Awesome, and at the end of the day, having the functionality you *are* looking for is what really matters. Glad you found that variable! John > > Thanks and best, > > Brian vdB