Re: Feature request: IDs for everything

[Rodrigo Morales <moralesrodrigo1100@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1864 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 2467 bytes --]