TLDR: one of my most cherished actions is a search filter that displays full lines of context as search results…
We’re spoilt for choice when it comes to ways of searching for things in Drafts. The Drafts list, the quick search interface, the search filter in the app.SelectDraft interface… not to mention a few different actions (e.g. @flohgro’s “search drafts” action)…
That said, the way I use Drafts, there are a couple of speed bumps in the native search functions built into Drafts that none of the other actions I’ve thus far found have offered solutions for. And after experimenting with “block level referencing” in other personal knowledge management apps, I wanted to see what might be possible along those lines in Drafts.
When I refer to a “block”, I’m really just referring to a line (or paragraph, if a line extends beyond your margins). The base unit of information in Drafts is a draft. The base unit of information in some of the better-known contemporary PKM apps is the “block”. In those apps, each page or document might be considered a collection of blocks, and each block in one of those pages/documents would be addressable, allowing you to link to and/or recombine blocks to suit a desired context. Practical example: let’s say I’ve got a series of different meeting notes. In each of those meeting notes, I may have a list of captured tasks assigned to different colleagues by name. A block level filter might allow me to surface a fully legible list of tasks on the basis of an individual colleague’s name.
If you’re good about working with Drafts’ base unit of information in mind, you might create a draft per information item, in which case the appeal of what I’ve just described might not be so compelling. I try but often fail to do this. My daily notes, for example, contain an overview of everything I’ve done in a day, potentially referencing a range of different projects, people, ideas…
With all this in mind, I cobbled together an action that attends to the following considerations:
- It displays the full line/paragraph containing a search result. This is the “block level” part. The search results become a kind of meta-document based on the search term. Each search result becomes a fully contextualised reference. And it becomes a little easier to intuit potential/unexpected links between drafts on the basis of these related “blocks”.
- It allows for further filtering within search results, with highlighting of terms in the list. This is really just a function of the MGCheckListPrompt library that this action depends upon.
- Selecting an option from the list loads the appropriate draft AND highlights the selected instance of the search term within that draft. This is a boon in a longer draft where the paragraph containing the search term might be buried somewhere in the text, and it’s incredibly useful to go straight from a high level search to a specific location within a draft.
- It offers a few different ways to specify a search query. If any text is selected, the action uses the selected text as the basis for the search. If not, the action displays a prompt with a text field, allowing you to specify a search term. If there are any wiki-links in the line your cursor’s currently sitting on, those wiki-links will also be offered as selectable options.
- It displays results from drafts sorted in modified order, and displays the modification dates of those drafts in relative formats, which my mind is able to process much more easily in a list/menu like this.
I’ve mentioned it in the notes above, but this action wouldn’t exist without the MGCheckListPrompt. @mattgemmell be praised. His action is an incredibly useful HTML list/menu interface and library that I’ve used as a basis for several custom filters and menu actions. If you’re so inclined to deep-dive this action’s code to see what you can derive from it, you can pretty confidently credit Matt for anything elegant and functional, and blame me for everything else.
There’s further thinking about the relative value of remembering things vs searching for things vs discovering unexpected connections between things, and how important search is for resurfacing things, but that’s for a different post (I should really restart my blog…).
As with the other posts in this series, the thinking here is presented in hope of further discussion rather than as an endpoint, whether that discussion is centred on whether this does/doesn’t seem useful for the way you use Drafts, or any suggestions/questions that might help refine the code.