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:31:58 +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=001a114b0ae20bfc49054446016f Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:45085) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cKAyN-0001yF-9H for emacs-orgmode@gnu.org; Thu, 22 Dec 2016 16:32:24 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cKAyL-0001Hd-RI for emacs-orgmode@gnu.org; Thu, 22 Dec 2016 16:32:23 -0500 Received: from mail-lf0-x236.google.com ([2a00:1450:4010:c07::236]:34601) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cKAyL-0001GW-Cu for emacs-orgmode@gnu.org; Thu, 22 Dec 2016 16:32:21 -0500 Received: by mail-lf0-x236.google.com with SMTP id y21so126966242lfa.1 for ; Thu, 22 Dec 2016 13:32:20 -0800 (PST) In-Reply-To: <87k2arznhu.fsf@ericabrahamsen.net> 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 --001a114b0ae20bfc49054446016f Content-Type: text/plain; charset=UTF-8 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 > > > --001a114b0ae20bfc49054446016f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear all,

before continuing this discus= sion, and before reinventing, you might want to take a look at how org-id.e= l currently does create unique IDs.=C2=A0 In particular, take a look at the= se variables:

org-id-prefix
org-id-metho= d
org-id-include-domain

In particular, t= he docstring of the variable org-id-method is

=C2=A0 "The method that should be used to create new IDs.
<= br>
An ID will consist of the optional prefix specified in `org-i= d-prefix',
and a unique part created by the method this varia= ble specifies.

Allowed values are:

<= /div>
org =C2=A0 =C2=A0 =C2=A0 =C2=A0Org's own internal method, usi= ng 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 th= e
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0computer.=C2=A0 See th= e variable `org-id-include-domain'.

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



Hope this help= s.

Carsten


On Thu, Dec 22, 2016 at 10:02 = PM, Eric Abrahamsen <eric@ericabrahamsen.net> wrote:
Ch= ristophe Schockaert <R3vLibre@ci= tadels.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



--001a114b0ae20bfc49054446016f--