EFLS / zetteldeft

A Zettelkasten system! Or rather, some functions on top of the emacs deft package.
https://efls.github.io/zetteldeft
GNU General Public License v3.0
394 stars 42 forks source link

Enable custom ID generation #74

Closed jeffvalk closed 4 years ago

jeffvalk commented 4 years ago

Closes #68

EFLS commented 4 years ago

Looking really nice! Thanks for including elaborate documentation in the .org. I'll take a closer look one of these days and play around with the new code.

jeffvalk commented 4 years ago

Good documentation is a good thing. :slightly_smiling_face:

The example code in the .org should provide everything needed to play with the updated code. And unless the user sets the zetteldeft-custom-id-function variable, behavior remains completely unchanged.

EFLS commented 4 years ago

I took the liberty of making some minor changes to proposed the documentation.

One question: is there any reason title is not an optional argument in the new zetteldeft-generate-id?

EFLS commented 4 years ago

Also, when thinking about Luhmann-style IDs (as discussed in #66), what makes most sense to use as input for a new ID, is the ID of its parent: in such a system, every note branches from an existing note.

I'm wondering whether (and how) configuring something like that would be possible with the current system. Not yet, I think? As this would rely on where and how a new note is created, which currently can't be taken into account by the new zetteldeft-generate-id function.

(To be clear: this doesn't need to be part of the current PR, I'm simply thinking about future ideas.)

jeffvalk commented 4 years ago

is there any reason title is not an optional argument in the new zetteldeft-generate-id?

Yes. The idea is to guarantee that a custom ID function will always have all available information about a note when creating its ID. In zetteldeft's current design, title is always known when zetteldeft-generate-idis called, and hence not optional.

jeffvalk commented 4 years ago

Also, when thinking about Luhmann-style IDs (as discussed in #66), what makes most sense to use as input for a new ID, is the ID of its parent: in such a system, every note branches from an existing note.

Yes, that makes sense.

I'm wondering whether (and how) configuring something like that would be possible with the current system Not yet, I think? As this would rely on where and how a new note is created, which currently can't be taken into account by the new zetteldeft-generate-id function.

This would introduce a new dimension to note creation. To accommodate this, we could simply add an optional parent-id argument to zetteldeft-generate-id.

EFLS commented 4 years ago

To accommodate this, we could simply add an optional parent-id argument to zetteldeft-generate-id.

Good to hear. But then the functions to create new files would require an overhaul too -- and there are still some questions related to such "branching" types of notes (for example, branching only makes sense when creating a new note from an existing one). Let's leave that for a separate discussion.

Thanks for your useful contribution!

jeffvalk commented 4 years ago

To accommodate this, we could simply add an optional parent-id argument to zetteldeft-generate-id.

Good to hear. But then the functions to create new files would require an overhaul too -- and there are still some questions related to such "branching" types of notes (for example, branching only makes sense when creating a new note from an existing one). Let's leave that for a separate discussion.

If kept simple, it could be done without altering the existing "create note" functions. But yes, this discussion is better left for #66.

Thanks for your useful contribution!

Of course!