> 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 <moralesrodrigo1...@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.git...@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 >> >>
