Re: [PATCH] org-id: allow using parent's existing id in links to headlines

["Rick Lupton" <mail@ricklupton.name>]

I realised there is another question here about how search strings are used in org-id links.

Consider this example file:


* Heading
:PROPERTIES:
:ID:       06E767E6-6145-45EB-B736-D350449126EC
:END:

#+name: named-thing
#+begin_example
Hi!
#+end_example


By default (`org-id-link-to-org-use-id` is nil), with point on `#+name: named-thing`, calling `org-store-link` will give a link like `[[file:test.org::named-thing][named-thing]]` which leads directly to the named example block. Different uses can also lead to search strings which link to headings, selected text in the region, or the current line's text.

When `org-id-link-to-org-use-id` is non-nil, none of this happens -- calling `org-store-link` anywhere within the subtree will result in a link `[[id:06E767E6-6145-45EB-B736-D350449126EC][Heading]]` with no additional search string.

My previous patch changes the behaviour when `org-id-link-to-org-use-id` has a new value (`inherit`) in two ways:

(a) org-ids from parent headings are considered when choosing the ID to link to, and 
(b) search strings are added to the link

But these are actually two independent things. So my question is: should search strings be added to all org-id links?

This would make org-id links more powerful/precise (because you can link to more precise locations within the subtree), and simplifies the code in `org-store-link` in my patch (because point [b] above would apply to all org-id links, not just the new 'inherit ones), but it could change the behaviour when calling `org-store-link` with an active region or when point is on a named element.

Depending on the answer, I can update the patch accordingly.

Thanks,
Rick