Re: Feature request: IDs for everything

[Max Nikulin]

On 21/10/2023 20:05, Ihor Radchenko wrote:
> Tor Erlend Fjelde writes:
>
> > I was wondering if there's a reason why we couldn't have IDs a la
> > org-id.el for everything? It seem to me that it would be useful to use
> > something like `#+ID` in place of `#+NAME` for tables, blocks, etc. as
> > well as headlines.

I think, another complication is referring source code blocks as 
variable values in header arguments and as noweb fragments. It would be 
great to be possible to specify "id:UUID" instead of fuzzy names. 
Perhaps it may be solved by explicit calls to new functions. If 
possible, I would avoid proliferation of keyword in favor of "#+name: 
id:UUID"

And there are references to particular lines inside code blocks...

> Apart from #+NAME, we also have radio <<<targets>>> that can be used a
> link anchors (#+NAME or other affiliated keywords are not allowed, for
> example, in items).

I think, you mean <<anchors>>, not <<<radio>>> targets that activates 
plain text words. It seems, the latter cannot be currently exported as 
explicit links [[radio][Radio]]. I am unsure what conflicts may appear 
during attempt to allow optional explicit types, e.g. <<id:UUID>>.

> We also discussed linking to #+name and <<<target>>> globally, without
> specifying the file path.

From my point of view, it should be either global id:UUID links or 
file:doc.org::name local links.

> 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?

>   [[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.