From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Abrahamsen Subject: Re: Properties ID vs. CUSTOM_ID Date: Thu, 22 Dec 2016 13:02:05 -0800 Message-ID: <87k2arznhu.fsf@ericabrahamsen.net> 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> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:58572) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cKAVU-0008AB-A4 for emacs-orgmode@gnu.org; Thu, 22 Dec 2016 16:02:33 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cKAVQ-0004tE-DO for emacs-orgmode@gnu.org; Thu, 22 Dec 2016 16:02:32 -0500 Received: from [195.159.176.226] (port=48143 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cKAVQ-0004sM-7K for emacs-orgmode@gnu.org; Thu, 22 Dec 2016 16:02:28 -0500 Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1cKAVF-0003Ph-P4 for emacs-orgmode@gnu.org; Thu, 22 Dec 2016 22:02:17 +0100 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: emacs-orgmode@gnu.org 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