Feature suggestion: using a custom sorting function in dblocks.

[MirkoHernandez]

Currently dblocks can only be sorted by component. It would be nice to be able to specify a sorting function in the dblocks parameters. Here is a possible implementation that modifies denote-sort-files so that It uses any kind of sorting function.

(defun denote-sort-files (files component &optional reverse)
  (let* ((files-to-sort (copy-sequence files))
         (sort-fn (when component
		    (or 
                      (pcase component
			('title #'denote-sort-title-lessp)
			('keywords #'denote-sort-keywords-lessp)
			('signature #'denote-sort-signature-lessp))
		      (when (functionp component) component))))
         (sorted-files (if sort-fn (sort files sort-fn) files-to-sort)))
    (if reverse
        (reverse sorted-files)
      sorted-files)))

[protesilaos]

Thank you! I just made the change. It is a bit different than what you suggest there, but it should do the same thing.

Please try it and let me know how it goes. Also, I am interested to learn more about the use-case. We can document it in the manual.

[MirkoHernandez]

Thanks!, it is great to have this feature in the future. My current most frequent use of the dblock is for describing Luhmann Id sections, for example, let's say we have a note with signature 6, then a dblock with regexp "6[^0-9-]*--" can display links to "descendant" notes (6a,6b,6c, etc), it works like a mini table of contents.

[protesilaos]

From: Mirko Hernández ***@***.***> Date: Sun, 29 Dec 2024 08:32:08 -0800 Thanks!, it is great to have this feature in the future.

You are welcome!

My current most frequent use of the dblock is for describing Luhmann Id sections, for example, let's say we have a note with signature 6, then a dblock with regexp "6[^0-9-]*--" can display links to "descendant" notes (6a,6b,6c, etc), it works like a mini table of contents.

Oh, this is nice! By the way, I have the <denote-sequence.el> in a separate branch: <https://github.com/protesilaos/denote/tree/sequence-notes-extension>. It will benefit from the insights of people like you who are more familiar with the zettelkasten workflow. The plan is to merge this into main once I can no longer find any bugs. It should be close. A brief descrription of it here: <https://protesilaos.com/codelog/2024-12-25-emacs-denote-sequence-notes/>.

…

-- Protesilaos Stavrou https://protesilaos.com

[MirkoHernandez]

I tried the denote-sequence commands (briefly), the new functionality looks amazing, I'm already thinking about moving some notes to the new sequence format. Here are some ideas.

• Dired commands to view sections are kind of essential; convenient initially but after the sections get 30 or 40 notes it becomes difficult to read those in Dired (even sorted), since there is no indentation or advanced syntax highlighting. Also it is nice to be able to see clusters of related notes.
• Navigation commands are extremely useful, it would be a good idea to provide them.
• Some dwim commands for note creation, since as the list of notes increases it becomes cumbersome to select a target note for creation, even with filtering there can be from 3 up to 10 candidates.

Some commands could ease the transition to sequence notes. The re-parent command is good to have, a nice addition would be a command that adds a child signature to a link using the current note's signature.

[protesilaos]

Thank you for the feedback! I created a couple of "do-what-I-mean" commands, namely, denote-sequence-new-child-of-current and denote-sequence-new-sibling-of-current. I guess we can have something similar for Dired, such as to only show for the current tree (the ultimate parent of the current sequence, all of its siblings, and children thereof) or only for the subtree (siblings and all children). Is this the idea?

We can probably put these in a bespoke tabulated-list-mode buffer, though we will still not have a tree-like view. Maybe there is some way to do that in a clean way.

[MirkoHernandez]

I guess we can have something similar for Dired, such as to only show for the current tree (the ultimate parent of the current sequence, all of its siblings, and children thereof) or only for the subtree (siblings and all children). Is this the idea?

Yes, exactly, moving between sections in Dired itself. I find it very useful, I rarely use the normal Dired command this days; after surpassing a certain number of notes it becomes more useful to navigate section by section.

Recently (last few weeks) I have been exploring that approach (for denote-folgezettel) using a global variable (a hash table with the current Dired directory as keys and the signature sections as values); this way some Dired section commands can be used in the Dired buffer using the stored signature. I works but there is probably a better approach leveraging Dired functionality, maybe Dired has some local variables can be used for that purpose. Right now I'm not sure how the state can be maintained (or passed around) between different Dired buffers.

We can probably put these in a bespoke tabulated-list-mode buffer

I was not aware of this mode , it looks promising, but it seems like it would require some non-trivial buffer manipulation for creating an UI.

[protesilaos]

Yes, exactly, moving between sections in Dired itself. I find it very useful, I rarely use the normal Dired command this days; after surpassing a certain number of notes it becomes more useful to navigate section by section.

Interesting! I will how best to approach this. There are several of these commands which need to operate on the entire tree, so I guess whatever underlying functionality will be shared.

Recently (last few weeks) I have been exploring that approach (for denote-folgezettel)

Oh, I was not aware of this package! Do you think we can proceed with a joint effort here, such that we combine the available functionality? Or is your package really different from what denote-sequence is doing right now? I have not tried it yet or read the documentation...

works but there is probably a better approach leveraging Dired functionality, maybe Dired has some local variables can be used for that purpose. Right now I'm not sure how the state can be maintained (or passed around) between different Dired buffers.

I am not sure. I know there is hierarchy.el built into Emacs, which may be the tool to use going forward. I have not experimented with it yet, though I imagine it will be useful for such sequences of notes. This way, we will not need to do anything with Dired that it was not designed to handle.

I was not aware of this mode , it looks promising, but it seems like it would require some non-trivial buffer manipulation for creating an UI.

Indeed, it is probably not the right tool on its own. Though hierarchy.el is using it, so we will find out.

[MirkoHernandez]

Oh, I was not aware of this package! Do you think we can proceed with a joint effort here, such that we combine the available functionality?

I was about to suggest something like this but I was unsure about what the scope of the new denote-sequence. Is the focus on the new sequence id format ? or would it be possible to generalize denote-sequence. The Luhmann id could be used as an alternative format for a particular silo with just the customization of some dir-locals variables (or create any silo with custom sequence format).
It would be great to have Luhmann id support in denote out of the box, could you clarify if this is the idea?

Or is your package really different from what denote-sequence is doing right now? I have not tried it yet or read the documentation...

The approach is very similar: manipulating signatures for note creation, note navigation, etc. The basic operations are the same, (fetch note using signature, create note using signature) but with a different signature type, so It seems possible to me to abstract the core operations so that they work with any kind of sequence type.