Re: Feature request: IDs for everything

[Ihor Radchenko]

Max Nikulin <manikulin@gmail.com> writes:

>> If we simply allow id: links to point to non-headings, it will be a
>> major breaking change that may affect third-party packages. So, we
>> need to design the extended ids carefully to avoid breakage.
>
> A defcusom user options whether id:UUID links for non-heading elements 
> are allowed. It is just an opinion/idea and nothing more.

> Are ids for whole files (placed before first headings) are problematic 
> for 3rd party packages?

Fair point. Even existing id links may not always point to a heading
(when pointing to IDs in top-level property drawer). So, the potential
breakage I was talking about is already there, and third-party packages
already have to adapt.

I still do not feel confident that it will be safe to blindly change
org-id in the proposed way though. Although I cannot think of clear
examples why it would cause problems worse compared to the existing id:
links to files. So, it may just be my unmotivated concern.

>>   [[id:unique-file-id:object-id-inside-the-file]]
>
> Perhaps than it should be id:FILE-UUID::SEARCH with usual search options 
> like #CUSTOM_ID, *Heading, etc., with the new variant id:OBJECT-UUID. 
> However I am unsure if search should be limited to a subtree if 
> HEADING-UUID is specified instead of FILE-UUID.

I indeed meant "::" search option. Sorry for the typo.

In any case, I agree with Tor that search option is less elegant. If we
can go for direct UUIDs, let's do it.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>