|
From: | TRS-80 |
Subject: | Any reason not to generate my own custom ID value (NOT CUSTOM_ID)? |
Date: | Thu, 10 Sep 2020 16:02:45 -0400 |
User-agent: | Roundcube Webmail/1.3.13 |
I could in fact gush all day, however people are busy, so, on to the main issue... :)
It seems to me that there is nothing really stopping me from inserting whatever value I like for value of "ID" Property. Based on brief experimentation, org-store-link and org-insert-link seem to happily accept whatever value is already there (which I entered manually, for testing purposes).
However I seem to recall reading some warning somewhere about this, although I cannot seem to find it right now.
What I would like to do, is generate my own ID values in a more human readable format, something "ISO-like" for example "2020-09-10-1433" (as opposed to the default "uuid" method). These sort of ID are still "Unique" (well, within my own system, anyway) as long as I am not generating them more often than once per minute[0]. And they have the advantages of being shorter, human readable, and meaningful.
Even when org-id-link-to-org-use-id and org-id-track-globally are both set to "t", org-id seems happy to insert my "ISO-like" ID right into the hash table and org-id-locations-file.
I do need the "across files" functionality. My understanding is that this is main difference between ID and CUSTOM_ID (the latter being local only to the file). Unless I am misunderstanding?
So, what am I missing here? Any reason(s) /not/ to use my own custom ID value?
In addition to the general case, one particular area I am unsure about (as I have yet to get it working) is how this all works out with HTML export, as that is something I also wanted to get working at some point.
I tried studying some of the related sources (as well as mailing list archive), but could not seem to reach a conclusive answer. I was hoping that some more knowledgeable people could confirm whether this is a really bad idea, or not. Any feedback would be greatly appreciated!
Cheers! TRS-80[0] It could easily be extended to second (or further) resolution, if needed. For me, minute resolution will be fine.
[Prev in Thread] | Current Thread | [Next in Thread] |