Well, the default timestamps / IDs are only down to the minute, not even the second, so this is an important issue indeed.

Derp! Of course you are right.

Now realizing we are talking about minutes, and not seconds, which of the following should our implementation do?

Simply give error message in minibuffer, and not allow user to do anything until one minute has passed.
- On one hand, this is probably the simplest implementation.
- OTOH, I really don't like my computer being obstinate with me. I am the one who is in charge here. lol So...
Automatically advance the timestamp to the next minute (perhaps with a message to the user)?
- Could get complex if they are doing some rapid fire note adding. Although properly coded would be something like a recursive forward checking algorithm in case eg. +3 notes have already been added...
Make this behavior configurable?
Extend the resolution to seconds (add 2 digits)?
- I don't like this. I rather prefer the nice, shorter ID, given how frequently the IDs show up everywhere.

On balance, I think I prefer option 1, at least for a first pass (and maybe even forever).

I can't help but wonder how often this really actually happens (so if you are reading this, please add your $0.02!). Speaking only for myself, I know I am editing a new note for at least one minute, and often more. I think that if you are doing Zettelkasten correctly that you are similarly putting some thought into it (editing, writing, etc.). However I also realize that some times you are just "capturing" things to come back to later (and then perhaps, even rapid-fire...). So, yeah...

So I suppose that determining how frequently this happens will help us really strike the right balance between eg. option 1 and option 4, above.

Moreover, as of a couple of months ago, zetteldeft-custom-id-function can be used to to generate IDs in custom fashion. Ideally, a general check for duplicate IDs should take this into account.

Yes, I think the correct place would be to put it right before any sort of ID were generated, whether custom or not.

The general check is the better option, I think, and should be easy enough to implement: simply check whether a filename with such a freshly generated string already exists and throw a warning if it does. There is currently no general function that identifies out duplicate IDs.

OK, cool. Thanks for the insight. I think we have at least that part of it nailed down. the "general check" function could actually return "first available time stamp" in the event we decide to go with option 2, above.

In fact, suddenly option 2 is sounding more elegant, and not terribly difficult to implement, I don't think, especially given the fact that "There is currently no general function that identifies out duplicate IDs."

But now I am thinking more about implications of zetteldeft-custom-id-function. I just took a look briefly at that. Maybe require it to also accept "next available time stamp" in addition to 'TITLE'?

But my head starting to hurt now. And I think we should decide first on implementation behavior. So I will revisit later.

Generated IDs are not unique when multiple per minute are created #71

Description

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions