Max Nikulin <maniku...@gmail.com> writes: >> 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? Fair point. Even existing id links may not always point to a heading (when pointing to IDs in top-level property drawer). So, the potential breakage I was talking about is already there, and third-party packages already have to adapt. I still do not feel confident that it will be safe to blindly change org-id in the proposed way though. Although I cannot think of clear examples why it would cause problems worse compared to the existing id: links to files. So, it may just be my unmotivated concern. >> [[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. I indeed meant "::" search option. Sorry for the typo. In any case, I agree with Tor that search option is less elegant. If we can go for direct UUIDs, let's do it. -- 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>
