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 <dominik@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 <eric@ericabrahamsen.net
> > wrote:
>
>> Christophe Schockaert <R3vLibre@citadels.eu> writes:
>>
>> > Eric Abrahamsen writes:
>> >
>> >> Karl Voit <devnull@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
>>
>>
>>
>