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 09:06:26 +0800 [thread overview] Message-ID: <87pn6ti0kt.fsf@localhost> (raw) In-Reply-To: <7689df3cbba5ea4afec672d80f99c590@isnotmyreal.name> > 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 TRS-80 <trs-80@isnotmyreal.name> writes: > On 2020-09-10 18:20, Samuel Wales wrote: >> this or something similar has definitely been discussed on this >> mailing list. so you are not alone. > > Yes, I also thought certainly this must have been discussed before. I > did try searching the list, but I think the relevant search terms are > too common, short ("ID", etc.) and/or too close to unrelated things > (i.e. CUSTOM_ID when I am looking for "custom ID", etc.) to produce > any good results. Or maybe my search-fu is just bad. > >> although i undersatnd the whole thing as readable id's. dunno if that >> is the prupose. > > Essentially, yes, more readable. But also shorter, and perhaps most > importantly, /meaningful/. > >> maybe something like a timestamp and then the usual id would give you >> pretty good uniqueness. > > The uniqueness I outlined in OP (down to minute) is plenty enough for > my use-case. The /last/ thing I want to do is to go the other way, and > make the ID even longer! > > 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. > > Thanks, > TRS-80
next prev parent reply other threads:[~2020-09-11 1:07 UTC|newest] Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-09-10 20:02 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 [this message] 2020-09-11 1:31 ` TRS-80 2020-09-11 7:51 ` Ihor Radchenko 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=87pn6ti0kt.fsf@localhost \ --to=yantar92@gmail.com \ --cc=emacs-orgmode@gnu.org \ --cc=trs-80@isnotmyreal.name \ --subject='Re: Any reason not to generate my own custom ID value (NOT CUSTOM_ID)?' \ /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
Code repositories for project(s) associated with this 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).