Re: Feature request: IDs for everything

[Tor Erlend Fjelde]

> What could be the added benefits of having such a header argument? I can 
> think of this benefit: #+NAME would be used for referencing them through a 
> human-friendly name and the name could change and the #+ID would be an UUID 
> that is not expected to change.

This is indeed one use-case I had in mind!


Generally speaking, I would imagine the motivation is the same as for ID vs. 
CUSTOM_ID for headlines? As in, most arguments made for the introduction of 
org-id.el in the first place can be made about linking to blocks, etc. too? I 
haven't seen the original discussions around this, so I'm only speeculating 
here.

What I specifically had in mind is mainly about what you can expect from an ID 
vs. NAME. IIUC the ID property is meant to be a "globally" unique identifier, 
while something like NAME is generally only meant to only be /locally/ unique.
Hence, if you want to interact with such references programmatically, it's 
useful to have an a "globally" consistent way of referencing not just 
headlines, but also blocks, etc.

A fairly prominent example is org-roam.el, which, when they moved to v2, 
decided to solely rely on IDs rather than allowing all standard forms of Org 
links exactly because "global" consistency is so important for them.

org-id.el also just provides a lot of convenient functionality, e.g. automatic 
creation of ID if it does not yet exist, which would similarly benefit linking 
to non-files and -headlines.

Hope that clearifies a bit!

All the best,
Tor


On Fri, 20/10/2023, Rodrigo Morales <moralesrodrigo1100@gmail.com> wrote:

> Currently, headlines can have an ID (see minimal working example below):
>
> #+BEGIN_SRC org
> * My headline 1
> * My headline 2
> :PROPERTIES:
> :ID: e8745be0-906d-4e02-b427-d298f5751f6c
> :END:
> #+END_SRC
>
> Blocks can't have IDs, but you could use a UUID as the for blocks (see
> minimal working example below). You can do the same with tables.
>
> #+BEGIN_SRC org
> ,#+NAME: 412f567b-26ce-4f21-b07f-f5296c830314
> ,#+BEGIN_SRC sh
> seq 1 3
> ,#+END_SRC
>
> ,#+RESULTS: 412f567b-26ce-4f21-b07f-f5296c830314
> ,#+begin_example
> 1
> 2
> 3
> ,#+end_example
>
> ,#+HEADER: :noweb yes
> ,#+BEGIN_SRC sh
> echo foo <<412f567b-26ce-4f21-b07f-f5296c830314()>>
> ,#+END_SRC
>
> ,#+RESULTS:
> ,#+begin_example
> foo 1
> foo 2
> foo 3
> foo
> ,#+end_example
> #+END_SRC
>
> What I understand from your message is that you would like to have a new
> header argument called #+ID: that could be used for code blocks and tables.
> Am I right? If so, I have a question: What could be the added benefits of
> having such a header argument? I can think of this benefit: #+NAME would be
> used for referencing them through a human-friendly name and the name could
> change and the #+ID would be an UUID that is not expected to change.
>
> On Fri, 20 Oct 2023 at 19:13, Tor Erlend Fjelde <tor.github@gmail.com>
> wrote:
>
>> Hi all,
>>
>> 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.
>> Would this go against the intended design of org-id.el, or is this a
>> change that would be welcome but that no one has gotten around to
>> implementing yet?
>>
>> Also, sorry if this is not correct way to go about this; it's my first
>> time posting to a mailing list. Let me know if there are some guidelines or
>> something somewhere that I should read and make use of.
>>
>> All the best,
>> Tor
>>
>>