And one more remark. A main reason for the CUSTOM_ID (and my only use of it, really) it to make HTML targets stable and meaningful. In the following file
* aaaa * bbbb :PROPERTIES: :CUSTOM_ID: Lotsofbshere :END: you can have a stable link to file.html#Lotsofbshere Carsten On Thu, Dec 22, 2016 at 10:31 PM, Carsten Dominik <domi...@uva.nl> wrote: > Dear all, > > before continuing this discussion, and before reinventing, you might want > to take a look at how org-id.el currently does create unique IDs. In > particular, take a look at these variables: > > org-id-prefix > org-id-method > org-id-include-domain > > In particular, the docstring of the variable org-id-method is > > "The method that should be used to create new IDs. > > An ID will consist of the optional prefix specified in `org-id-prefix', > and a unique part created by the method this variable specifies. > > Allowed values are: > > org Org's own internal method, using an encoding of the current > time to > microsecond accuracy, and optionally the current domain of the > computer. See the variable `org-id-include-domain'. > > uuid Create random (version 4) UUIDs. If the program defined in > `org-id-uuid-program' is available it is used to create the ID. > Otherwise an internal functions is used." > > > > Hope this helps. > > Carsten > > > On Thu, Dec 22, 2016 at 10:02 PM, Eric Abrahamsen <e...@ericabrahamsen.net > > wrote: > >> Christophe Schockaert <r3vli...@citadels.eu> writes: >> >> > Eric Abrahamsen writes: >> > >> >> Karl Voit <devn...@karl-voit.at> writes: >> >> >> >>> I'd prefer using manually written :ID: instead since migration would >> >>> not be trivial to me. >> >> >> >> You could also use the `org-property-set-functions-alist' trick with >> the >> >> :ID: property. If you added an "ID" entry to that alist, Org's usual >> >> automatic id creation would be unaffected, but if you set ID manually, >> >> you could write a function that would first prompt for your >> >> human-readable string, then check for ID uniqueness and append random >> >> characters to your string until it was unique. I think that would be a >> >> nice addition to org-id.el. >> >> >> >> Eric >> > I thikn the tricky part would be that we can only ensure ID uniqueness >> > for the current agenda at the time of the ID creation. What if we later >> > merge another set of files where ID were created independantly to our >> > acustomed agenda files ? >> > >> > I like the idea of assigning a date since we would reduce chances to >> > define at the same time the same string and the same day. If meticulous, >> > we could assign a date and a time or random string as you suggest, Eric >> > (a tiny UUID :). >> > >> > I think I read somewhere the first inactive timestamp could be used to >> > tag an entry with a date. At least, I do that frequently. >> > >> > Thus, if available, we could even use it as a date when creating the ID >> > in order to have an indication of the creation time for the heading >> > instead of creation time of the link. >> > >> > Here it is for my suggestions. >> > >> > Dates might not be appropriate for every situation, though... >> >> I think including some sort of timestamp in the id would likely solve >> the problem of future conflicts. I don't think adding the actual date >> into the ID string would be that useful (how often would you be >> comparing dates from the ID property?), but the human-readable string >> could have a hash of the string plus (current-time) appended to it. Or, >> perhaps better, a hash of the outline path plus current-time. >> >> E >> >> >> >
