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

[Rick Lupton]

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