> Although we have at least one caveat that we need to consider - the > current users of the id: links blindly assume that they always link to > headings. This includes many third-party packages, like org-roam. > > 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. For > example, `org-id-find' and other API function may need to work in two > modes: (1) legacy, only searching for headings; (2) new, searching for > anything. This can, for example, be done via an extra optional argument.
This is a very good point, and definitively makes things non-trivial. Nonetheless, I'd be happy to have a go at it if this seems like the way to go! But I'll probably need quite a bit of help in the process as I haven't contributed to Org before. > As an alternative option, we had a proposal that extends id: links to > have a search option: > > [[id:<ID>:search-string]] > > Then, we may have top-level drawer like > > :PROPERTIES: > :ID: unique-file-id > :END: > > And then refer to anything inside the file as > > [[id:unique-file-id:object-id-inside-the-file]] Indeed; I was actually about to have a go at implementing this because I thought this would be the quickest way of adding support for referencing blocks in something like org-roam. But this does seem like a sub-optimal solution vs. just adding support for more general IDs, and so I thought it would be better to see if that could be done first (hence I'm here). All the best, Tor On Sat, 21/10/2023, Ihor Radchenko <yanta...@posteo.net> wrote: > Tor Erlend Fjelde <tor.git...@gmail.com> 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. > > This has been discussed in the past. > > 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). > > We also discussed linking to #+name and <<<target>>> globally, without > specifying the file path. > >> 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? > > Mostly nobody has gotten around. > > Although we have at least one caveat that we need to consider - the > current users of the id: links blindly assume that they always link to > headings. This includes many third-party packages, like org-roam. > > 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. For > example, `org-id-find' and other API function may need to work in two > modes: (1) legacy, only searching for headings; (2) new, searching for > anything. This can, for example, be done via an extra optional argument. > > ----- > > As an alternative option, we had a proposal that extends id: links to > have a search option: > > [[id:<ID>:search-string]] > > Then, we may have top-level drawer like > > :PROPERTIES: > :ID: unique-file-id > :END: > > And then refer to anything inside the file as > > [[id:unique-file-id:object-id-inside-the-file]] > > -- > 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>
