I did some digging and ended at the function org-link-expand-abbrev. According to the org-documentation, abbreviations should be written with:
[[linkword:tag]] however the regular expression doing the matching in the function also allows the following: [[linkword::tag]] The greed of the regular expression makes it a requirement to use four colons when using abbreviation and search. Also, all types of searching works, not only the headline-search as I stated earlier. Just wanted to clear this out /Gustav 2011/10/31 Gustav Wikström <gustav.e...@gmail.com>: > 2011/10/31 Suvayu Ali <fatkasuvayu+li...@gmail.com>: >> Hi Gustav, >> >> On Mon, 31 Oct 2011 14:55:27 +0100 >> Gustav Wikström <gustav.e...@gmail.com> wrote: >> >>> This works when adding "::" to the end of the link. But with this >>> setting I cannot use the link as a simple file-link, eg. the following >>> does not work: >>> >>> #+LINK: foo file:/long/path/to/file/foo.org:: >>> [[foo][Description]] >>> >>> When trying to follow this link I get an error saying that there is >>> "no such file: /long/path/to/file/foo.org::" >> >> Of course that won't work! The resulting link is not a valid link >> syntax. Since you don't specify a tag, the final link looks like this: >> >> [[file:/path/to/file.org::]] >> >> which is incorrect. >> >> From a test the following worked nicely. >> >> #+LINK: odir2 file:~/org/coding.org >> >> [[odir2][link to file]] >> >> So in conclusion, if you want to use both bare file/directory links as >> well as headline/search links, you would have to define two separate >> link shortcuts. > > Yes, I'm aware of this. And this is the reason of my initial question. > Should it really be necessary to specify two separate links to the > same file when I want to both link to the file directly and link it > with a search? > > Thus, this works: > > #+LINK: foo file:/long/path/to/file/foo.org > [[foo::::*<heading search>]] > > but this does not: > > #+LINK: foo file:/long/path/to/file/foo.org > [[foo::::<search>]] > > I find the use of four ":" a bit strange, but I guess this is only a > limit of my understanding a.t.m. In my view the first colon should be > stating the start of the "tag" and the rest of the string the tag > itself. This leaves three colons for the tag which in my view is one > to many. But it seems to work. And this is what I'm scratching my head > about. > > I also suspect a bug hidden somewhere, since headlines can be searched > for but not text inside the document. > > Anyone got any input on this? > /Gustav >