First, I want to express my sincere and heart-felt gratitude to Carsten (and other contributors) for making and sharing this wonderful piece of software. I have come to refer to it as "one of the gateway drugs to Emacs" (the other being Magit, IMHO). It was certainly one of (if not /the/) main reason(s) why I started using Emacs initially. 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.
[-- Attachment #1: Type: text/plain, Size: 3106 bytes --] Hi TRS-80, Your approach should work just fine. So fine, in fact, that it's already kind of built in! Configure org-id-method and set it to 'ts and you'll get timestamps as ID instead of uuid. I do believe the manual lacks a description for this. Not entirely sure though, and can't check atm. But the configuration is there none the less, and supported. Kind regards Gustav ________________________________ From: Emacs-orgmode <emacs-orgmode-bounces+gustav=whil.se@gnu.org> on behalf of TRS-80 <trs-80@isnotmyreal.name> Sent: Thursday, September 10, 2020 10:02:45 PM To: emacs-orgmode@gnu.org <emacs-orgmode@gnu.org> Subject: Any reason not to generate my own custom ID value (NOT CUSTOM_ID)? First, I want to express my sincere and heart-felt gratitude to Carsten (and other contributors) for making and sharing this wonderful piece of software. I have come to refer to it as "one of the gateway drugs to Emacs" (the other being Magit, IMHO). It was certainly one of (if not /the/) main reason(s) why I started using Emacs initially. 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. [-- Attachment #2: Type: text/html, Size: 4691 bytes --]
On 2020-09-10 18:00, Gustav Wikström wrote:
> Hi TRS-80,
>
> Your approach should work just fine. So fine, in fact, that it's
> already kind of built in! Configure org-id-method and set it to 'ts
> and you'll get timestamps as ID instead of uuid.
>
> I do believe the manual lacks a description for this. Not entirely
> sure though, and can't check atm. But the configuration is there none
> the less, and supported.
>
> Kind regards
>
> Gustav
Hi Gustav,
Thanks for the fast reply.
I am aware of the 'ts' option to org-id-method which does not seem to
be documented in manual, only docstring of its defcustom in org-id.el.
I had left that detail out for the sake of brevity. :)
My problem with that is that I do not like the format it outputs which
is "%Y%m%dT%H%M%S.%6N" (in other words, output which looks like
"20200910T180910.747026"). Only a little bit better than the "uuid"
option, IMHO! :)
It would be great if that format-time-string was a configurable
variable, instead of hard coded, but alas it is not. Well, since we
are now on that subject, perhaps I should ask is there some reason for
this? Or would Bastien perhaps consider something like that? :)))
Regards,
TRS-80
this or something similar has definitely been discussed on this mailing list. so you are not alone. although i undersatnd the whole thing as readable id's. dunno if that is the prupose. maybe something like a timestamp and then the usual id would give you pretty good uniqueness. On 9/10/20, TRS-80 <trs-80@isnotmyreal.name> wrote: > First, I want to express my sincere and heart-felt gratitude to Carsten > (and other contributors) for making and sharing this wonderful piece of > software. I have come to refer to it as "one of the gateway drugs to > Emacs" (the other being Magit, IMHO). It was certainly one of (if not > /the/) main reason(s) why I started using Emacs initially. > > 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. > > -- The Kafka Pandemic Please learn what misopathy is. https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html
On 2020-09-10 18:20, Samuel Wales wrote: > this or something similar has definitely been discussed on this > mailing list. so you are not alone. Yes, I also thought certainly this must have been discussed before. I did try searching the list, but I think the relevant search terms are too common, short ("ID", etc.) and/or too close to unrelated things (i.e. CUSTOM_ID when I am looking for "custom ID", etc.) to produce any good results. Or maybe my search-fu is just bad. > although i undersatnd the whole thing as readable id's. dunno if that > is the prupose. Essentially, yes, more readable. But also shorter, and perhaps most importantly, /meaningful/. > maybe something like a timestamp and then the usual id would give you > pretty good uniqueness. The uniqueness I outlined in OP (down to minute) is plenty enough for my use-case. The /last/ thing I want to do is to go the other way, and make the ID even longer! I do appreciate all the replies so far. However as I plan on relying on this to implement some quite critical functionality for a package I am working on (a sort of Zettelkasten / TiddlyWiki in Orgmode if you will) I would feel a lot more comfortable with some additional reassurences that what I am planning is not some crazy or bad idea. Thanks, TRS-80
> I do appreciate all the replies so far. However as I plan on relying > on this to implement some quite critical functionality for a package I > am working on (a sort of Zettelkasten / TiddlyWiki in Orgmode if you > will) I would feel a lot more comfortable with some additional > reassurences that what I am planning is not some crazy or bad idea. Is there any particular reason why you even need to display :ID: value to the user? If only id: links are concerned, link description can be made short and human-readable. Best, Ihor TRS-80 <trs-80@isnotmyreal.name> writes: > On 2020-09-10 18:20, Samuel Wales wrote: >> this or something similar has definitely been discussed on this >> mailing list. so you are not alone. > > Yes, I also thought certainly this must have been discussed before. I > did try searching the list, but I think the relevant search terms are > too common, short ("ID", etc.) and/or too close to unrelated things > (i.e. CUSTOM_ID when I am looking for "custom ID", etc.) to produce > any good results. Or maybe my search-fu is just bad. > >> although i undersatnd the whole thing as readable id's. dunno if that >> is the prupose. > > Essentially, yes, more readable. But also shorter, and perhaps most > importantly, /meaningful/. > >> maybe something like a timestamp and then the usual id would give you >> pretty good uniqueness. > > The uniqueness I outlined in OP (down to minute) is plenty enough for > my use-case. The /last/ thing I want to do is to go the other way, and > make the ID even longer! > > I do appreciate all the replies so far. However as I plan on relying > on this to implement some quite critical functionality for a package I > am working on (a sort of Zettelkasten / TiddlyWiki in Orgmode if you > will) I would feel a lot more comfortable with some additional > reassurences that what I am planning is not some crazy or bad idea. > > Thanks, > TRS-80
On 2020-09-10 21:06, Ihor Radchenko wrote:
>> I do appreciate all the replies so far. However as I plan on relying
>> on this to implement some quite critical functionality for a package I
>> am working on (a sort of Zettelkasten / TiddlyWiki in Orgmode if you
>> will) I would feel a lot more comfortable with some additional
>> reassurences that what I am planning is not some crazy or bad idea.
>
> Is there any particular reason why you even need to display :ID: value
> to
> the user? If only id: links are concerned, link description can be made
> short and human-readable.
>
> Best,
> Ihor
Yes, most of the time I expect I will be using Orgmode double bracket
style
links which will, as you say, hide the id: from the user, allowing to
replace it with whatever desired text in the form of the link
description.
However, I just (strongly) prefer the shorter "ISO-like" ID for many
reasons, as already mentioned (shorter, meaningful, etc.). I just find
that style much, much more elegant.
Besides, as an ID, they are plenty "Unique" for my use case, with the
default minute resolution (however even that, is configurable in my
implementation, by way of a time-format variable, should anyone need
more).
I suppose if we ever get to a world where people start linking to each
others' individual publicly published zettel, I may regret the decision.
However Ted Nelson has already been working on such a thing for some
decades already, and we are still not there yet, so I don't think I will
need to worry about that any time soon. ;) Even if so, it would be a
very
small implementation change anyway.
Cheers,
TRS-80
[-- Attachment #1: Type: text/plain, Size: 271 bytes --] > However, I just (strongly) prefer the shorter "ISO-like" ID for many > reasons, as already mentioned (shorter, meaningful, etc.). I just find > that style much, much more elegant. I guess it does not take much to add this functionality. Patch attached. Best, Ihor [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #2: 0001-Allow-customised-ID-format-for-ts-org-id-method.patch --] [-- Type: text/x-diff, Size: 1406 bytes --] From 6f2fff0cb7ce294d863ee0527463e5713a790078 Mon Sep 17 00:00:00 2001 From: Ihor Radchenko <yantar92@gmail.com> Date: Fri, 11 Sep 2020 15:42:53 +0800 Subject: [PATCH] Allow customised ID format for `ts' `org-id-method' Introduce new custom variable `org-id-ts-format' defining the ID format for `ts' ID generation method. The default value is the same as old hard-coded ID format string. --- lisp/org-id.el | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/lisp/org-id.el b/lisp/org-id.el index f8af52964..512703269 100644 --- a/lisp/org-id.el +++ b/lisp/org-id.el @@ -128,6 +128,10 @@ nil Never use an ID to make a link, instead link using a text search for :group 'org-id :type 'string) +(defcustom org-id-ts-format "%Y%m%dT%H%M%S.%6N" + "Default format for IDs generated using `ts' `org-id-method'. +The format should be suitable to pass as an argument to `format-time-string'.") + (defcustom org-id-method 'uuid "The method that should be used to create new IDs. @@ -380,7 +384,7 @@ So a typical ID could look like \"Org:4nd91V40HI\"." (concat "@" (message-make-fqdn)))))) (setq unique (concat etime postfix)))) ((eq org-id-method 'ts) - (let ((ts (format-time-string "%Y%m%dT%H%M%S.%6N")) + (let ((ts (format-time-string org-id-ts-format)) (postfix (if org-id-include-domain (progn (require 'message) -- 2.26.2 [-- Attachment #3: Type: text/plain, Size: 1741 bytes --] TRS-80 <trs-80@isnotmyreal.name> writes: > On 2020-09-10 21:06, Ihor Radchenko wrote: >>> I do appreciate all the replies so far. However as I plan on relying >>> on this to implement some quite critical functionality for a package I >>> am working on (a sort of Zettelkasten / TiddlyWiki in Orgmode if you >>> will) I would feel a lot more comfortable with some additional >>> reassurences that what I am planning is not some crazy or bad idea. >> >> Is there any particular reason why you even need to display :ID: value >> to >> the user? If only id: links are concerned, link description can be made >> short and human-readable. >> >> Best, >> Ihor > > Yes, most of the time I expect I will be using Orgmode double bracket > style > links which will, as you say, hide the id: from the user, allowing to > replace it with whatever desired text in the form of the link > description. > > However, I just (strongly) prefer the shorter "ISO-like" ID for many > reasons, as already mentioned (shorter, meaningful, etc.). I just find > that style much, much more elegant. > > Besides, as an ID, they are plenty "Unique" for my use case, with the > default minute resolution (however even that, is configurable in my > implementation, by way of a time-format variable, should anyone need > more). > > I suppose if we ever get to a world where people start linking to each > others' individual publicly published zettel, I may regret the decision. > However Ted Nelson has already been working on such a thing for some > decades already, and we are still not there yet, so I don't think I will > need to worry about that any time soon. ;) Even if so, it would be a > very > small implementation change anyway. > > Cheers, > TRS-80
Hi,
TRS-80 <trs-80@isnotmyreal.name> writes:
> I am aware of the 'ts' option to org-id-method which does not seem to
> be documented in manual, only docstring of its defcustom in org-id.el.
Can you propose a patch for the documentation?
It is written as an Org file, so editing and patch the manual should
be a pleasure.
Thanks in advance!
--
Bastien
Hi Ihor,
Ihor Radchenko <yantar92@gmail.com> writes:
>> However, I just (strongly) prefer the shorter "ISO-like" ID for many
>> reasons, as already mentioned (shorter, meaningful, etc.). I just find
>> that style much, much more elegant.
>
> I guess it does not take much to add this functionality.
It looks okay to me, for after 9.4. Thanks for putting this patch
together!
--
Bastien
Hi Ihor, Ihor Radchenko <yantar92@gmail.com> writes: >> However, I just (strongly) prefer the shorter "ISO-like" ID for many >> reasons, as already mentioned (shorter, meaningful, etc.). I just find >> that style much, much more elegant. > > I guess it does not take much to add this functionality. > > Patch attached. Thanks. Can you update the patch with a correct Changelog entry and a note to etc/ORG-NEWS announcing the new option? See https://orgmode.org/worg/org-contribute.html#commit-messages if it helps. -- Bastien
[-- Attachment #1: Type: text/plain, Size: 19 bytes --] See the attached. [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #2: 0001-Allow-customised-ID-format-for-ts-org-id-method.patch --] [-- Type: text/x-diff, Size: 1461 bytes --] From bc492bd2fb87912289c135006b6fbeaca93ba181 Mon Sep 17 00:00:00 2001 From: Ihor Radchenko <yantar92@gmail.com> Date: Fri, 11 Sep 2020 15:42:53 +0800 Subject: [PATCH] Allow customised ID format for `ts' `org-id-method' * lisp/org-id.el (org-id-new): Use `org-id-ts-format' as ID format for `ts' ID generation method. (org-id-ts-format): New custom variable for `ts' ID format. The default value is the same as old hard-coded ID format string. --- lisp/org-id.el | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/lisp/org-id.el b/lisp/org-id.el index f8af52964..512703269 100644 --- a/lisp/org-id.el +++ b/lisp/org-id.el @@ -128,6 +128,10 @@ nil Never use an ID to make a link, instead link using a text search for :group 'org-id :type 'string) +(defcustom org-id-ts-format "%Y%m%dT%H%M%S.%6N" + "Default format for IDs generated using `ts' `org-id-method'. +The format should be suitable to pass as an argument to `format-time-string'.") + (defcustom org-id-method 'uuid "The method that should be used to create new IDs. @@ -380,7 +384,7 @@ So a typical ID could look like \"Org:4nd91V40HI\"." (concat "@" (message-make-fqdn)))))) (setq unique (concat etime postfix)))) ((eq org-id-method 'ts) - (let ((ts (format-time-string "%Y%m%dT%H%M%S.%6N")) + (let ((ts (format-time-string org-id-ts-format)) (postfix (if org-id-include-domain (progn (require 'message) -- 2.26.2 [-- Attachment #3: Type: text/plain, Size: 596 bytes --] Bastien <bzg@gnu.org> writes: > Hi Ihor, > > Ihor Radchenko <yantar92@gmail.com> writes: > >>> However, I just (strongly) prefer the shorter "ISO-like" ID for many >>> reasons, as already mentioned (shorter, meaningful, etc.). I just find >>> that style much, much more elegant. >> >> I guess it does not take much to add this functionality. >> >> Patch attached. > > Thanks. Can you update the patch with a correct Changelog entry and a > note to etc/ORG-NEWS announcing the new option? > > See https://orgmode.org/worg/org-contribute.html#commit-messages if it > helps. > > -- > Bastien
Ihor Radchenko <yantar92@gmail.com> writes:
> See the attached.
Thanks, but you forgot the note to etc/ORG-NEWS announcing the new
option la mission. Can you add it in the same patch?
--
Bastien
[-- Attachment #1: Type: text/plain, Size: 7 bytes --] Done. [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #2: 0001-Allow-customised-ID-format-for-ts-org-id-method.patch --] [-- Type: text/x-diff, Size: 2093 bytes --] From c479d8b229140029a3a8454dd933dab7322fafc4 Mon Sep 17 00:00:00 2001 From: Ihor Radchenko <yantar92@gmail.com> Date: Fri, 11 Sep 2020 15:42:53 +0800 Subject: [PATCH] Allow customised ID format for `ts' `org-id-method' * lisp/org-id.el (org-id-new): Use `org-id-ts-format' as ID format for `ts' ID generation method. (org-id-ts-format): New custom variable for `ts' ID format. The default value is the same as old hard-coded ID format string. * etc/ORG-NEWS (New option ~org-id-ts-format~): Announce the new custom variable. --- etc/ORG-NEWS | 6 ++++++ lisp/org-id.el | 6 +++++- 2 files changed, 11 insertions(+), 1 deletion(-) diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS index 87c5696d8..7e3957c10 100644 --- a/etc/ORG-NEWS +++ b/etc/ORG-NEWS @@ -363,6 +363,12 @@ HTML. Functions in this hook are run after ~org-agenda-filter~ is called. +*** New option ~org-id-ts-format~ + +Earlier, IDs generated using =ts= method had a hard-coded format (i.e. =20200923T160237.891616=). +The new option allows user to customise the format. +Defaults are unchanged. + ** Removed or renamed functions and variables *** Deprecated ~org-flag-drawer~ function diff --git a/lisp/org-id.el b/lisp/org-id.el index f8af52964..512703269 100644 --- a/lisp/org-id.el +++ b/lisp/org-id.el @@ -128,6 +128,10 @@ nil Never use an ID to make a link, instead link using a text search for :group 'org-id :type 'string) +(defcustom org-id-ts-format "%Y%m%dT%H%M%S.%6N" + "Default format for IDs generated using `ts' `org-id-method'. +The format should be suitable to pass as an argument to `format-time-string'.") + (defcustom org-id-method 'uuid "The method that should be used to create new IDs. @@ -380,7 +384,7 @@ So a typical ID could look like \"Org:4nd91V40HI\"." (concat "@" (message-make-fqdn)))))) (setq unique (concat etime postfix)))) ((eq org-id-method 'ts) - (let ((ts (format-time-string "%Y%m%dT%H%M%S.%6N")) + (let ((ts (format-time-string org-id-ts-format)) (postfix (if org-id-include-domain (progn (require 'message) -- 2.26.2 [-- Attachment #3: Type: text/plain, Size: 248 bytes --] Bastien <bzg@gnu.org> writes: > Ihor Radchenko <yantar92@gmail.com> writes: > >> See the attached. > > Thanks, but you forgot the note to etc/ORG-NEWS announcing the new > option la mission. Can you add it in the same patch? > > -- > Bastien
Ihor Radchenko <yantar92@gmail.com> writes:
> Done.
Applied as 6c75b0021, thanks!
--
Bastien
> Thanks, but you forgot the note to etc/ORG-NEWS announcing the new > option la mission. Do I miss something or the need to add ORG-NEWS entry is not mentioned in the contribution page? Best, Ihor Bastien <bzg@gnu.org> writes: > Ihor Radchenko <yantar92@gmail.com> writes: > >> See the attached. > > Thanks, but you forgot the note to etc/ORG-NEWS announcing the new > option la mission. Can you add it in the same patch? > > -- > Bastien
Ihor Radchenko <yantar92@gmail.com> writes:
>> Thanks, but you forgot the note to etc/ORG-NEWS announcing the new
>> option la mission.
>
> Do I miss something or the need to add ORG-NEWS entry is not mentioned
> in the contribution page?
If you can, please go ahead and fix this. Thanks,
--
Bastien
Hi Ihor, Ihor Radchenko <yantar92@gmail.com> writes: >> Thanks, but you forgot the note to etc/ORG-NEWS announcing the new >> option la mission. > > Do I miss something or the need to add ORG-NEWS entry is not mentioned > in the contribution page? I updated https://orgmode.org/worg/org-contribute.html to mention etc/ORG-NEWS, thanks.