emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Ihor Radchenko <yantar92@gmail.com>
To: TRS-80 <trs-80@isnotmyreal.name>, emacs-orgmode@gnu.org
Subject: Re: Any reason not to generate my own custom ID value (NOT CUSTOM_ID)?
Date: Fri, 11 Sep 2020 15:51:35 +0800	[thread overview]
Message-ID: <87h7s4iwe0.fsf@localhost> (raw)
In-Reply-To: <11d07d7c64137cc1fb512e9cc546ab08@isnotmyreal.name>

[-- Attachment #1: Type: text/plain, Size: 271 bytes --]

> 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


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Allow-customised-ID-format-for-ts-org-id-method.patch --]
[-- Type: text/x-diff, Size: 1406 bytes --]

From 6f2fff0cb7ce294d863ee0527463e5713a790078 Mon Sep 17 00:00:00 2001
From: Ihor Radchenko <yantar92@gmail.com>
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


[-- Attachment #3: Type: text/plain, Size: 1741 bytes --]



TRS-80 <trs-80@isnotmyreal.name> 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

  reply	other threads:[~2020-09-11  7:52 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-10 20:02 Any reason not to generate my own custom ID value (NOT CUSTOM_ID)? TRS-80
2020-09-10 22:00 ` Gustav Wikström
2020-09-10 22:16   ` TRS-80
2020-09-13 20:18     ` Bastien
2020-09-10 22:20 ` Samuel Wales
2020-09-10 23:33   ` TRS-80
2020-09-11  1:06     ` Ihor Radchenko
2020-09-11  1:31       ` TRS-80
2020-09-11  7:51         ` Ihor Radchenko [this message]
2020-09-13 20:19           ` Bastien
2020-09-23  7:19           ` Bastien
2020-09-23  7:43             ` [PATCH] " Ihor Radchenko
2020-09-23  7:48               ` Bastien
2020-09-23  8:08                 ` Ihor Radchenko
2020-09-23  8:30                   ` Bastien
2020-09-23  8:40                 ` Ihor Radchenko
2020-09-23  8:48                   ` Bastien
2021-04-25 14:19                   ` Bastien

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87h7s4iwe0.fsf@localhost \
    --to=yantar92@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    --cc=trs-80@isnotmyreal.name \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).