From mboxrd@z Thu Jan 1 00:00:00 1970 From: Carsten Dominik Subject: Re: Properties ID vs. CUSTOM_ID Date: Thu, 22 Dec 2016 22:39:02 +0100 Message-ID: References: <2016-08-25T14-36-57@devnull.Karl-Voit.at> <877fb429j4.fsf@saiph.selenimh> <2016-08-25T17-05-15@devnull.Karl-Voit.at> <87mvg2t8g0.fsf@artlab.createcnix.lan> <2016-12-12T12-38-45@devnull.Karl-Voit.at> <2016-12-12T15-59-38@devnull.Karl-Voit.at> <2016-12-18T13-12-13@devnull.Karl-Voit.at> <2016-12-20T20-43-27@devnull.Karl-Voit.at> <2016-12-22T11-00-17@devnull.Karl-Voit.at> <2016-12-22T16-27-34@devnull.Karl-Voit.at> <87mvfoc627.fsf@ericabrahamsen.net> <874m1voii4.fsf@artlab.createcnix.lan> <87k2arznhu.fsf@ericabrahamsen.net> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=94eb2c0d9682498d3f0544461ad9 Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:48159) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cKB5C-0003S4-E9 for emacs-orgmode@gnu.org; Thu, 22 Dec 2016 16:39:27 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cKB5A-0006cu-SR for emacs-orgmode@gnu.org; Thu, 22 Dec 2016 16:39:26 -0500 Received: from mail-lf0-x231.google.com ([2a00:1450:4010:c07::231]:34716) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cKB5A-0006c4-EZ for emacs-orgmode@gnu.org; Thu, 22 Dec 2016 16:39:24 -0500 Received: by mail-lf0-x231.google.com with SMTP id y21so127057625lfa.1 for ; Thu, 22 Dec 2016 13:39:24 -0800 (PST) In-Reply-To: List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: "Emacs-orgmode" To: Eric Abrahamsen Cc: org-mode list --94eb2c0d9682498d3f0544461ad9 Content-Type: text/plain; charset=UTF-8 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 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 > wrote: > >> Christophe Schockaert writes: >> >> > Eric Abrahamsen writes: >> > >> >> Karl Voit 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 >> >> >> > --94eb2c0d9682498d3f0544461ad9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
And one more remark.

A main reason for = the CUSTOM_ID (and my only use of it, really) it to make HTML targets stabl= e and meaningful.=C2=A0 In the following file


=
* aaaa
* bbbb
=C2=A0 :PROPERTIES:
=
=C2=A0 :CUSTOM_ID: Lotsofbshere
=C2=A0 :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 cont= inuing this discussion, and before reinventing, you might want to take a lo= ok at how org-id.el currently does create unique IDs.=C2=A0 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
<= br>
=C2=A0 "The method that should be used to create ne= w IDs.

An ID will consist of the optional prefix s= pecified in `org-id-prefix',
and a unique part created by the= method this variable specifies.

Allowed values ar= e:

org =C2=A0 =C2=A0 =C2=A0 =C2=A0Org's own in= ternal method, using an encoding of the current time to
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0microsecond accuracy, and optionally the = current domain of the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0co= mputer.=C2=A0 See the variable `org-id-include-domain'.

<= /div>
uuid =C2=A0 =C2=A0 =C2=A0 Create random (version 4) UUIDs.=C2=A0 = If the program defined in
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0`org-id-uuid-program' is available it is used to create the ID.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Otherwise an internal functi= ons is used."



=
Hope this helps.
<= div>
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 migra= tion 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 manua= lly,
>> you could write a function that would first prompt for your
>> human-readable string, then check for ID uniqueness and append ran= dom
>> 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 late= r
> merge another set of files where ID were created independantly to our<= br> > 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 meticulou= s,
> we could assign a date and a time or random string as you suggest, Eri= c
> (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 I= D
> 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




--94eb2c0d9682498d3f0544461ad9--