From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id WMlrE9ssW18tWgAA0tVLHw (envelope-from ) for ; Fri, 11 Sep 2020 07:52:59 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1 with LMTPS id OKOyDdssW1/VcAAAbx9fmQ (envelope-from ) for ; Fri, 11 Sep 2020 07:52:59 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 88265940366 for ; Fri, 11 Sep 2020 07:52:58 +0000 (UTC) Received: from localhost ([::1]:36184 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kGdrd-0000Cc-Do for larch@yhetil.org; Fri, 11 Sep 2020 03:52:57 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:53102) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kGdrK-0000CN-Bh for emacs-orgmode@gnu.org; Fri, 11 Sep 2020 03:52:38 -0400 Received: from mail-pj1-x102a.google.com ([2607:f8b0:4864:20::102a]:37004) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kGdrI-00056v-ID for emacs-orgmode@gnu.org; Fri, 11 Sep 2020 03:52:37 -0400 Received: by mail-pj1-x102a.google.com with SMTP id kk9so1307203pjb.2 for ; Fri, 11 Sep 2020 00:52:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:in-reply-to:references:date:message-id:mime-version; bh=ZYibUSfbsFw60bdVPB8z9M9PwNszih84ILInwARCNPM=; b=sAan71wXqG8Qoq0wfJH9ea4Q6EMd9WU8G4ZiYpCZgrL0b+lwsT0PdF01U55QFW3wDT A/AjCBZCCUFECgT9hHqc4Dabkkq1Z/yo1e3td0iY6zwFzP2wK4G6romRcugmv5FHoSod KbisrmZk2DJN8KDFk/YN55RgrCcSBsVf7/0c9mwr7lk3MBfKEEeMdWipXKvu1YQBoQqP R09gGKH32q1ZSU4BzI+2HigyF90tjeDovjJom3jEeKKDB/RGUkxO5dF/FT2XkAVm/sDc Gl/9ltarEfqDeVHp20vopNOXqlciydjWhWqMF80DNMjWZDm8vfrxIbJxAoFlAVP50brX jtVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:in-reply-to:references:date :message-id:mime-version; bh=ZYibUSfbsFw60bdVPB8z9M9PwNszih84ILInwARCNPM=; b=re8yiwkSXrGD77pjYm+dd03n58M2INnGBgpIuM38cvQJkWeRyhRrzVkKbzh6kvVUCj vqBhSbnhOGwHI+V7+HmrHevJAEqQHaTI03MIVpRUsSh/sNnGkG8NMTbv5IEyry332HBO W0WbyA6NDJogiIXLEgET5NMHX30Uvr2ymU7SjrVfQwGynoy/r7+/D7Zx59ukCXwcf/vU 1mLwHBy+VIZZY/P5AR02PTWXAVPqcLfy3inC6OH6RsjqNuEaPX9OKybFXgFZ4+Epoi57 1UdukClxfUtB/yob6isw8IatAoC9o1lxsbMZKQDJdo+8YX5SlFa/qK6QxkybRPZ64cBW casw== X-Gm-Message-State: AOAM532dmsqLuM1a41t4UZv+BbUYAGTihoWxI1h4R+9XMVTQfJ1WgS8H 77O0NXcYeljDXL5iVSdPPpbNLAvss6Jss1SF X-Google-Smtp-Source: ABdhPJyOtduN+eBfswUzEL+a6eB1jd+a30sVamQwzH8H5ii+rpglwMUqLgudYPt4kuNKBZaGlBQChw== X-Received: by 2002:a17:90a:e98d:: with SMTP id v13mr1066110pjy.79.1599810755252; Fri, 11 Sep 2020 00:52:35 -0700 (PDT) Received: from localhost ([104.250.131.79]) by smtp.gmail.com with ESMTPSA id v12sm1151757pgk.81.2020.09.11.00.52.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 11 Sep 2020 00:52:34 -0700 (PDT) From: Ihor Radchenko To: TRS-80 , emacs-orgmode@gnu.org Subject: Re: Any reason not to generate my own custom ID value (NOT CUSTOM_ID)? In-Reply-To: <11d07d7c64137cc1fb512e9cc546ab08@isnotmyreal.name> References: <8e204de9ad9da09812991449c64d7aad@isnotmyreal.name> <7689df3cbba5ea4afec672d80f99c590@isnotmyreal.name> <87pn6ti0kt.fsf@localhost> <11d07d7c64137cc1fb512e9cc546ab08@isnotmyreal.name> Date: Fri, 11 Sep 2020 15:51:35 +0800 Message-ID: <87h7s4iwe0.fsf@localhost> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Received-SPF: pass client-ip=2607:f8b0:4864:20::102a; envelope-from=yantar92@gmail.com; helo=mail-pj1-x102a.google.com X-detected-operating-system: by eggs.gnu.org: No matching host in p0f cache. That's all we know. X-Spam_score_int: -17 X-Spam_score: -1.8 X-Spam_bar: - X-Spam_report: (-1.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: "Emacs-orgmode" X-Scanner: scn0 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20161025 header.b=sAan71wX; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (aspmx1.migadu.com: domain of emacs-orgmode-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=emacs-orgmode-bounces@gnu.org X-Spam-Score: -0.21 X-TUID: afIOe2VmyXYB --=-=-= Content-Type: text/plain > However, I just (strongly) prefer the shorter "ISO-like" ID for many > reasons, as already mentioned (shorter, meaningful, etc.). I just find > that style much, much more elegant. I guess it does not take much to add this functionality. Patch attached. Best, Ihor --=-=-= Content-Type: text/x-diff Content-Disposition: inline; filename=0001-Allow-customised-ID-format-for-ts-org-id-method.patch >From 6f2fff0cb7ce294d863ee0527463e5713a790078 Mon Sep 17 00:00:00 2001 From: Ihor Radchenko Date: Fri, 11 Sep 2020 15:42:53 +0800 Subject: [PATCH] Allow customised ID format for `ts' `org-id-method' Introduce new custom variable `org-id-ts-format' defining the ID format for `ts' ID generation method. The default value is the same as old hard-coded ID format string. --- lisp/org-id.el | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/lisp/org-id.el b/lisp/org-id.el index f8af52964..512703269 100644 --- a/lisp/org-id.el +++ b/lisp/org-id.el @@ -128,6 +128,10 @@ nil Never use an ID to make a link, instead link using a text search for :group 'org-id :type 'string) +(defcustom org-id-ts-format "%Y%m%dT%H%M%S.%6N" + "Default format for IDs generated using `ts' `org-id-method'. +The format should be suitable to pass as an argument to `format-time-string'.") + (defcustom org-id-method 'uuid "The method that should be used to create new IDs. @@ -380,7 +384,7 @@ So a typical ID could look like \"Org:4nd91V40HI\"." (concat "@" (message-make-fqdn)))))) (setq unique (concat etime postfix)))) ((eq org-id-method 'ts) - (let ((ts (format-time-string "%Y%m%dT%H%M%S.%6N")) + (let ((ts (format-time-string org-id-ts-format)) (postfix (if org-id-include-domain (progn (require 'message) -- 2.26.2 --=-=-= Content-Type: text/plain TRS-80 writes: > On 2020-09-10 21:06, Ihor Radchenko wrote: >>> I do appreciate all the replies so far. However as I plan on relying >>> on this to implement some quite critical functionality for a package I >>> am working on (a sort of Zettelkasten / TiddlyWiki in Orgmode if you >>> will) I would feel a lot more comfortable with some additional >>> reassurences that what I am planning is not some crazy or bad idea. >> >> Is there any particular reason why you even need to display :ID: value >> to >> the user? If only id: links are concerned, link description can be made >> short and human-readable. >> >> Best, >> Ihor > > Yes, most of the time I expect I will be using Orgmode double bracket > style > links which will, as you say, hide the id: from the user, allowing to > replace it with whatever desired text in the form of the link > description. > > However, I just (strongly) prefer the shorter "ISO-like" ID for many > reasons, as already mentioned (shorter, meaningful, etc.). I just find > that style much, much more elegant. > > Besides, as an ID, they are plenty "Unique" for my use case, with the > default minute resolution (however even that, is configurable in my > implementation, by way of a time-format variable, should anyone need > more). > > I suppose if we ever get to a world where people start linking to each > others' individual publicly published zettel, I may regret the decision. > However Ted Nelson has already been working on such a thing for some > decades already, and we are still not there yet, so I don't think I will > need to worry about that any time soon. ;) Even if so, it would be a > very > small implementation change anyway. > > Cheers, > TRS-80 --=-=-=--