[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [O] Properties ID vs. CUSTOM_ID

From: Carsten Dominik
Subject: Re: [O] Properties ID vs. CUSTOM_ID
Date: Thu, 22 Dec 2016 22:39:02 +0100

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
  :CUSTOM_ID: Lotsofbshere

you can have a stable link

to file.html#Lotsofbshere


On Thu, Dec 22, 2016 at 10:31 PM, Carsten Dominik <address@hidden> 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:


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.


On Thu, Dec 22, 2016 at 10:02 PM, Eric Abrahamsen <address@hidden> wrote:
Christophe Schockaert <address@hidden> writes:

> Eric Abrahamsen writes:
>> Karl Voit <address@hidden> 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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]