Search facility

[lmq-10]

Hello Prot (and Denote community as a whole). I have been using and enjoying this fantastic note-taking tool for a while. Eventually, as my collection of notes grew, I needed a search facility, and not content with the available options, I went and developed my own. Today I published the code and wrote documentation for it just in case someone finds it useful, too.

• https://github.com/lmq-10/denote-search

I think this feature is not planned (judging by #71), specially now that consult-denote exists, but there it is anyway!

[protesilaos]

Thank you for doing this! Do you want to prepare a brief description for our README here? We already mention other packages and I am happy to include yours there as well.

[lmq-10]

Oh, sure! Maybe something like this would work:

---

denote-search provides a search utility for Denote. It allows you to search for a regular expression in the content of your notes. Its main advantages over other similar tools are the possibility of filtering the results by file name and doing further searches in the files matched previously. This allows for advanced usage (think about finding a note with two or three specific words in different lines and with a specific keyword). More features are described in its comprehensive manual. denote-search builds upon standard Emacs libraries, namely Xref, and so it doesn't have external dependencies other than Denote itself.

---

Note that I haven't published the package to any ELPA yet. I wanted to see if there was any interest first. Also, I preferably would like to have it in GNU ELPA, but I still have to figure out the procedure.

[protesilaos]

About ELPA, you will need to assign copyright to the Free Software Foundation and then email the emacs-devel mailing list to ask for the inclusion of your package on ELPA. I have included the copyright assignment form in the manual of Denote. Evaluate this:

(info "(denote) Contributing")

Actually, you need this even for code that you submit to Denote.

---

About your package, I think what you are doing is useful. The question I have is if it makes sense to have it as part of the main Denote package or to keep it separate. The reason I am asking this is because we already have denote-sort-dired which is a search interface of sorts for file names. Maybe the current arrangement is fine, but I am happy to have it some other way if you think it makes sense.

[lmq-10]

Thank you for the information regarding copyright assignment.

About your question, I guess you'll know better. I tried to write denote-search in a way that would allow it to become part of Denote without issues, as an optional module if anything; it's pretty self-contained, has no dependencies, and its codebase is small. Naturally, I'd be very happy to see my little package integrated here, but again, that's up to you. I still have to assign copyright to the FSF though, but I plan to do it anyway.

(Oh, now that you mention denote-sort-dired, I realized that's a perfect way to start a search in a predefined set of files! I'll add a function to search in marked dired files to my package, it should be trivial. That way it will be better integrated, too.)

[protesilaos]

From: Lucas Quintana ***@***.***> Date: Tue, 31 Dec 2024 11:41:34 -0800 Thank you for the information regarding copyright assignment.

You are welcome!

About your question, I guess you'll know better. I tried to write `denote-search` in a way that would allow it to become part of Denote without issues, as an optional module if anything; it's pretty self-contained, has no dependencies, and its codebase is small. Naturally, I'd be very happy to see my little package integrated here, but again, that's up to you. I still have to assign copyright to the FSF though, but I plan to do it anyway.

It is also an open question for me: what do we all think is better in terms of organising the code we have. I have been adding these optional extensions to the main repo (like denote-sort.el, the Org dynamic blocks, and the new denote-sequence.el), but maybe they should all be their own little packages. The upside with having them all together is that they are more discoverable. The downside is that someone may get the impression the package is "bloated" because it does too many things. In terms of maintenance though, the workload is the same from my perspective as I would be maintaining the standalone packages as well. If we merge your code here, then I will grant you write access to the repo. I should have done the same with @jeanphilippegg, whose contributions I always merge. Alternatively, we split up the code to many smaller packages and take care to document the available options.

(Oh, now that you mention `denote-sort-dired`, I realized that's a perfect way to start a search in a predefined set of files! I'll add a function to search in marked dired files to my package, it should be trivial. That way it will be better integrated, too.)

Very well! Maybe we would want denote-sort-dired (or something like it) to eventually be part of your search facility rather than be in denote-sort.el. I think it makes sense conceptually.

…

-- Protesilaos Stavrou https://protesilaos.com