On Sat, Nov 15, 2025 at 9:29 PM Ihor Radchenko <[email protected]> wrote:
> Yes, you are right. `org-id-update-id-locations' only considers actual > ID properties, not generic default property setting. This is the same in > other places (e.g. `org-id-find-id-in-file'). > > Also, it feels awkward to use the global default ID as > reference. Because it is "default", it will be an ID for all the > headings without ID explicitly set, making such ID non-unique, which > goes against the idea of id: link design. I understand your point, I used to use ID under headings for a long time. However the `org-id-link-consider-parent-id` option was introduced in `org-mode 9.7` so the combination of top-level ID and the heading title is kind of URI in my usecase: Looking at my notes I see that the headings are usually on the first level (* heading 1) and the content of headings is quite short (3-15 lines) - I would say a typical project file with todos, notes etc. I heavily link between notes and the shortness of the headings means that adding ID inside the drawer (3 lines) increases the content of the heading by 20%-100%. I find myself to browse thru my notes without org-mode machinery quite frequently (mobile, terminal) and the option above to link just with top-level ID and heading title improved this workflow a lot. My feeling is this option made org-notes more human readable and light-weight (I just need to add top-level ID and all the linking functionality is here, there is no need to add PROPERTIES drawer with ID under the heading just for the purpose of linking). > I think that your use case should not be supported because of this > ambiguity. Thus, I do not think that current behavior of Org mode needs > to be changed. It is perfectly fine. Maybe my explanation above gives you more insight into why I started this thread. Also it seems to me I can write a custom function which gathers and adds one-line format of top-level IDs to `.orgids` database and that gives me the functionality I want. Regards Jaroslav
