Make it possible to rename/change the identifier

[protesilaos]

We have mentioned the titular idea before and we have the building blocks to make it happen. Modifying the identifier can be problematic, because it may result in duplicates (we have code to avoid this inside of the denote-directory, but it can still happen if the user renames files elsewhere and then consolidates them in a single directory). If there are such cases, we have to trust the user to resolve them or, maybe, we can provide a command that does that automatically.

I think this is the right time to provide the relevant points of entry. @jeanphilippegg You recently made changes to the denote-files-types. Are you also planning something along those lines? If yes, then I will wait for it. Otherwise, I will go ahead with some code and then we can iterate on it.

[jeanphilippegg]

Actually, yes!

I had the following 2 changes in mind before that:

• Cleanup the date handling functions. Since it is closely related to the id,
  I would make it consistent. There are some unecessary functions that I would
  like to address.

• Refactor denote-rewrite-front-matter and add the signature. The refactor
  involves handling all front matter components consistenty and address the
  points you mentionned in Suggestion where to place SIGNATURE in the front matter #366. We should be able to add/remove individual
  lines automatically when they are present. The signature can then be added
  to the front matter! This will also be useful to modify the front matter
  id/date.

After the above changes, I would have worked on allowing the modification of
the identifier (under the condition that there are no links to the note) and
maybe allow its absence. I want to make this possible using what we already
have for other components. Changing the date with denote-rename-file should
just change the date/id as expected (it does nothing right now). I would not
add any new commands specific to date/id, except maybe the convenience
denote-rename-file-date!

I planned on pushing some of these changes next weekend.

Did you have anything specific already on this?

[juh2]

In this context I would like to ask if you plan to make the date identifier more precise. Some years ago I bulk created 10.000 org-files with a script and I had to add milliseconds to the filename part that took the current date+time as identifier of the filename. Otherwise I would end up with files with the same timestamp. These are older org-files I manage in org-roam. Now that I want to migrate to denote, I run into problems as the migration skript at hand (https://github.com/bitspook/notes-migrator.git) does not support milliseconds and if I am unaware of a millisecond option in denote anyway.

I may solve this issue by reimporting the files from a sqlite database where I also store the information with a wait one second function, but then the script would run for several hours.

If denote had an option to evaluate a longer timestring in the filename I could just try to import them with the bitspook script or to newly export them from the database.

[jeanphilippegg]

I may solve this issue by reimporting the files from a sqlite database where I also store the information with a wait one second function, but then the script would run for several hours.

If denote had an option to evaluate a longer timestring in the filename I could just try to import them with the bitspook script or to newly export them from the database.

You can generate 10000 timestamps programatically without waiting one second between each, like this:

(defun generate-10000-dates ()
  (let ((current-date (date-to-time "20240101T000000"))
        (dates '()))
    (dotimes (_ 10000)
      (push current-date dates)
      (setq current-date (time-add current-date 1)))
    (nreverse dates)))

Then, rename your notes to use those timestamps and you should be able to migrate them to Denote.

---

As for the inclusion of the milliseconds in Denote, I don't think there is a plan for this.

A possible improvement in the future is to allow identifiers to be any string. If that is possible, then you can have milliseconds there. But there are a few necessary adjustments to do before this is possible.

[mentalisttraceur]

Re: greater precision in ID datetime: funny enough, I actually have ~10k files (and gradually growing) named with nanosecond precision (the names are just an ISO8601-conformant timestamp with extended precision: f.e. 20241202T143520,123456789Z).

I currently just treat those as non-Denoted names, and I never need to manually manipulate those files, but I sometimes think about generalizing my wrappers/reimplementations of Denote pieces to tolerate/accept an optional ,[0-9]+ at the end of the ID/datetime (or maybe even open it up as far as ,.*).

Not recommending/asking that you support that, just mentioning another unexpected in-the-wild use-case that Denoted naming (and UI improvements based on it) elegantly covers (once broadened/generalized just a tiny amount).

[mentalisttraceur]

re: milliseconds again: I just remembered, my earlier idea to make ID regex user-configurable would also enable users who want higher-precision datetimes as IDs.

[jeanphilippegg]

@mentalisttraceur, I don't know yet how we can support identifiers with milliseconds, but I am curious: do you know a function that converts a string with nanoseconds ("20240101T000000,123456789Z") to a Lisp timestamp?

Denote uses date-to-time to convert strings to date. However, it is only precise up to the seconds. On the other hand, it is quite flexible in what it accepts. It works with various input formats.

[mentalisttraceur]

@jeanphilippegg, the closest function I know is iso8601-parse - it will validate sub-second precision syntax, but return a decoded-time only precise to the second. However, decoded-time is allowed to hold a more precise lisp timestamp in its seconds slot, so if you want to get a full parse, you could run a datetime through iso8601-parse first, and then if that doesn't error out that means there's at most one [,.] in the string, and the stuff immediately after is the sub-second amount - could use the number of digits to tell precision, and build the (ticks . hz) form of timestamp from there...

That said, I was only imagining bare minimum support of alternate IDs - configurable recognition for linking/fontification/etc purposes, but no automatic generation/incrementation. So you would never need to parse them, they'd just be opaque strings.

[mentalisttraceur]

Oh, iso8601-parse can do it, we just need to pass t for the FORM argument!

• (iso8601-parse "20010203T040506,987654321Z" t)

  returns ((6987654321 . 1000000000) 5 4 3 2 2001 nil nil 0), and

• (iso8601-parse "20010203T040506,987Z" t)

  returns ((6987 . 1000) 5 4 3 2 2001 nil nil 0).

[jeanphilippegg]

That is good to know! I don't know how this could be used in Denote. date-to-time is still more flexible. But it is good to keep in mind!