Hacking `denote-rename-file` to allow changing the ID about denote

[jeanphilippegg]

I mentionned this once in the past in another issue, but I see the ID part of the file name as something that users should not really mess with. Its initial purpose was to allow linking between files. It would not even have existed in the file name if some kind of linking (that does not involve a database) existed. In general, I would recommend using title, keywords and signature for a note's meaningful data.

However, the identifier in file names have been made to be the current date, the manual refers to it as a date (as opposed to an identifier) and it is part of the front matter, by default. So we probably want it to mean more than just an identifier and I don't think it is that much of an issue to do so.

Starting from tomorrow, I will start making pull requests and try to remove restrictions in the file names, allow reordering the components, general cleanups to the codebase. I will look into adding a command to change a note's identifier. Such a command can be useful when doing some tests as well.

I have not decided in what order these will be done. It may be a few weeks for this function to be added.

[mentalisttraceur]

I see the ID part of the file name as something that users should not really mess with.

Alas, I know users, users are friends of mine, also enemies, in fact I too am a user sometimes, and I can confirm from personal experience we users mess with everything.

It would not even have existed in the file name if some kind of linking (that does not involve a database) existed

I totally get that. But, since it does exist, it's going to naturally inspire creative repurposing, and I think that's a good thing.

Of course, you don't have to support any particular creative repurposing, I'm just saying part of the power of the Denote naming convention is that the ID is (parseable as) a date+time and thus can serve any purpose that a datetime could.

[mentalisttraceur]

I will look into adding a command to change a note's identifier.

💡 What about overloading+renaming the ask-date optional argument to denote-rename-file?

So the signature becomes

(denote-rename-file FILE TITLE KEYWORDS SIGNATURE &optional DATE)

and the docstring would say

If FILE has a Denote-compliant identifier:

1. If optional DATE is nil, t, or an integer, retain the existing
   identifier while updating the TITLE, KEYWORDS, and SIGNATURE
   components of the file name.

2. If optional DATE is a string which is a valid identifier,
   update all components of the file name.

Else create an identifier based on the following conditions:

1. If optional DATE is t or an integer (such as with a prefix
   argument), prompt for a date and use it to derive the
   identifier.

2. If optional DATE is a string which is a valid identifier,
   use that as the identifier.

3. If optional DATE is nil (this is the case without a prefix
   argument), use the file attributes to determine the last
   modified date and format it as an identifier.

4. As a fallback, derive an identifier from the current time.

5. If the resulting identifier is not unique among the files in
   the variable ‘denote-directory’, increment it such that it
   becomes unique.

[mentalisttraceur]

It may be a few weeks for this function to be added.

Well if you want some help, I'm happy to make some PRs for some of these things I'm asking for.

[jeanphilippegg]

Well if you want some help, I'm happy to make some PRs for some of these things I'm asking for.

Sure! Some of them may also have been done by then.

[protesilaos]

Hey folks I am reading through all the discussions, but it is hard to write at length.

I mentionned this once in the past in another issue, but I see the ID part of the file name as something that users should not really mess with. Its initial purpose was to allow linking between files. It would not even have existed in the file name if some kind of linking (that does not involve a database) existed.

The ID is indeed needed for linking purposes, though it is also useful as a timestamp. For example, I often search for something like ^2024 to see what I published in a given year. But yeah, I get the point you are making.

I often want to change the ID part of a Denote-style file name [...]

The option to rewrite the ID has its use-cases. My concern though with such a feature is that it gives users too much power to shoot themselves in the foot. For example, if a file has links pointing to it and its identifier is changed, those links are now broken.

More generally, it makes things harder to explain/document because now we cannot guarantee that Denote never touches the identifiers.

I think the right approach here is to accommodate power users by making the code more flexible/hackable, but not expose any functionality that can be used directly, like a command, user option, or prefix argument.

What do you think?

Well if you want some help, I'm happy to make some PRs for some of these things I'm asking for.

These are welcome! Note that for non-trivial changes you will need to assign copyright to the Free Software Foundation, because Denote is distributed via GNU ELPA and this is the legal requirement we have to conform with.

[mentalisttraceur]

I think the right approach here is to accommodate power users by making the code more flexible/hackable, but not expose any functionality that can be used directly, like a command, user option, or prefix argument.

What do you think?

100% agree + works for me.

In fact, I now think this issue can be reduced down to just adding a function like denote-rewrite-front-matter (or adding an extra optional parameter to the end of the signature of that function), to enable updating the identifier and date front matter fields.

(Because I now realize that all the value of denote-rename-file is easy enough to reimplement with other functions that Denote already provides.)