Add utility for denote-find-file

[felipebalbi]

Hi Prot,

I spent a little time with denote and felt the need for a denote-find-file so I could easily visit a note without having to first visit the relevant dired buffer.

I came up with the following two utilities:

(defun fb/denote-title-and-file (file)
  "Given a denote FILE, produce a cons cell containing the file's
     title and the FILE path."
  (interactive)
  (cons (denote--retrieve-title-value file 'org) file))

(defun fb/denote-find-file ()
  "A utility to find a note using `completing-read'."
  (interactive)
  (let* ((files (denote--directory-files))
         (title-file-alist (mapcar #'fb/denote-title-and-file files))
         (titles (mapcar #'car title-file-alist)))
    (find-file (cdr (assoc (completing-read "Find Note: " titles) title-file-alist)))))

Perhaps there's some interest in integrating something like this as part of denote. What are your thoughts?

[protesilaos]

Hello @felipebalbi,

Perhaps there's some interest in integrating something like this as part of denote.

Let's leave this issue open as a point of discussion to read what others may have to say.

What are your thoughts?

I think it is not necessary. Users have different ways to access their files. Standard C-x C-f (find-file) already gives you minibuffer completion---you don't have to used Dired first.

There is a package called consult-bookmark which lets you pick a bookmarked directory and then uses find-file on its contexts. This is a general solution for all your regularly-visited directories.

Personally, when I don't do it through Dired I tend to use C-x p f (project-find-file) and related commands. This is because I treat my notes as a "project" with a git history, so it is easy to use the built-in capabilities for this. project-find-file is like find-file but only for the given project.

[felipebalbi]

Hello @felipebalbi,

Hi @protesilaos,

Perhaps there's some interest in integrating something like this as part of denote.

Let's leave this issue open as a point of discussion to read what others may have to say.

sure thing

What are your thoughts?

I think it is not necessary. Users have different ways to access their files. Standard C-x C-f (find-file) already gives you minibuffer completion---you don't have to used Dired first.

The difference, however, is that my suggestion above is extracting the note's title, instead of using the raw filename, which may provide for a more pleasant user experience, although it's debatable.

There is a package called consult-bookmark which lets you pick a bookmarked directory and then uses find-file on its contexts. This is a general solution for all your regularly-visited directories.

Personally, when I don't do it through Dired I tend to use C-x p f (project-find-file) and related commands.

Interesting, one benefit of this approach is that one can search for title and/or keywords. I'll probably use a combination of my suggestion above and filtering by keyword too. Wonder if I can figure out how to feed this information into marginalia and still allow for filtering on the keywords.

This is because I treat my notes as a "project" with a git history, so it is easy to use the built-in capabilities for this. project-find-file is like find-file but only for the given project.

I do too, all my notes are kept in a git repository as well.

[protesilaos]

The difference, however, is that my suggestion above is extracting the note's title, instead of using the raw filename, which may provide for a more pleasant user experience, although it's debatable.

Yes, that is an improvement. Though we would then need to make it more consistent across all our relevant prompts/interfaces, such as when creating a link to a file and when showing backlinks.

Interesting, one benefit of this approach is that one can search for title and/or keywords. I'll probably use a combination of my suggestion above and filtering by keyword too. Wonder if I can figure out how to feed this information into marginalia and still allow for filtering on the keywords.

I don't know how to achieve this, though I am happy to make it happen.

About filtering using the marginalia annotations, I think that is not possible directly. You could use embark to produce a buffer out of the completion candidates and then invoke something like consult-keep-lines. But it no longer is a minibufffer-level interaction.

[svnsbck]

Hi!

Interesting discussion. I have started to use the package consult-notes for these purposes. Once configured I only have to invoke consult-notes and then search through all my notes from the minubuffer using the title/tags. It's quite handy I think.

[protesilaos]

@svnsbck Good call! It is also mentioned in the Denote manual.

[telenieko]

instead of using the raw filename, which may provide for a more pleasant user experience, although it's debatable.

About improving user experience during note finding:

I'm not sure if this falls really within the scope of Denote. One of its design goals is Composability. Then it may make more sense to provide an example in README about how to achieve this with already existing packages.

this being: showing the title (and the keywords) in a visually appealing way instead of the filename.

The infrastructure is there (the necessary functions). What's missing is an example of the "glue" needed to tie different packages together.

The difference, however, is that my suggestion above is extracting the note's title

What would be the performance implications? Listing a directory's contents is quite fast on pretty much every system. But in order to fetch the title you would need to open every single note file during completion, every time. So, the more your note collection grows the slower it would get.

About user experience, the main difference between the filename or the title is casing and the keywords ("The Lord of the Rings +book" becomes "1234567890--the_lord_of_the_rings__book.txt". So, making it visually more appealing could done by using something like marginalia and some regex on the filename.

Meaning, you could either use faces to color the output of find-file (I recall there was some example about that?) or rewrite the output to show the title and keywords (from the filename) in columns (with Marginalia?).

[protesilaos]

Thank you @telenieko for your thoughts!

What would be the performance implications? Listing a directory's contents is quite fast on pretty much every system. But in order to fetch the title you would need to open every single note file during completion, every time. So, the more your note collection grows the slower it would get.

Perhaps this could work by leveraging the consult package's asynchronous functionality? Kind of like consult-find? But I have no knowledge of the internals.

This would be glue code, of course. Not something to add to denote.el.

Meaning, you could either use faces to color the output of find-file (I recall there was some example about that?)

We do this, for example, in the buffer where the backlinks are presented. Though adding faces to the completion UI may be tricky as it is uncharted territory for me. This seems to work with vertico, though I do not know if it is a good idea and/or what the possible downsides could be.

(completing-read
 "Do you see propertized candidates? "
 `(
   "one"
   
   ,(propertize "two" 'face 'error) ; red+bold

   "three"

   ,(propertize "four" 'face 'success) ; green+bold

   ,(format "%s--for-didactic-pursposes__testing_%s"
            (propertize "1234567890" 'face 'error)
            (propertize "hello" 'face 'success)
            )
   ))

[EFLS]

For what it's worth: I've been building on consult-notes package to achieve some of the things discussed here. In particular, I wanted to get an overview of what's in my notes folder, with note titles rather than file names. I've received some excellent help: mclear-tools/consult-notes#14

Adding things like keywords & number of words is possible as well by altering consult-notes-annotate-denote. That will be a next step.

[protesilaos]

Thank you @EFLS! I have not tested any of the code, but my impression is that this is promising. I still have a TODO for consult-notes: I have used it before but need to actually integrate it into my setup.

If you have something to share with other users, consider contacting the mailing list as well. Also, I am happy to include any of this in the manual, perhaps under the existing entry for consult-notes (mutatis mutandis).

[EFLS]

I might do that at some point, @protesilaos! I'm currently still tinkering and experimenting with it. Currently I have included in the Consult buffer, next to the title: keywords, number of words, subdirectory, and modified time. One major drawback of the current setup is: it's no longer possible to quickly filter by keyword (as the candidates shown are titles, not filenames), nor to narrow to a directory (e.g. /journal/).

[ssl19]

I might do that at some point, @protesilaos! I'm currently still tinkering and experimenting with it. Currently I have included in the Consult buffer, next to the title: keywords, number of words, subdirectory, and modified time. One major drawback of the current setup is: it's no longer possible to quickly filter by keyword (as the candidates shown are titles, not filenames), nor to narrow to a directory (e.g. /journal/).

You could check my modified version of that snippet, it provided such functionality.
mclear-tools/consult-notes#14 (comment)

[protesilaos]

Hello folks! My understanding is that the consult-notes package provides this functionality: https://github.com/mclear-tools/consult-notes

Closing this issue as it will not be part of core Denote.