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).