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
