Block level filtering/querying aka another option for searching for things in Drafts

1

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.

Happy Friday!

3 Likes
2

Excellent! Very useful, thanks. :+1:

1 Like
3

Man, I need to look at this. The task “try to get more context for search results in Drafts” has been sitting on my task list for ages, :smirk:

1 Like
4

Note: just pushed an update for better handling of relative dates…

5

Such a promising action, but maybe you’ve got a late bug? It’s missing all kinds of hits that the Drafts Quick Search finds readily…

1 Like
6

Thanks for the feedback! Any chance you can give me an example of a term you’re searching for that doesn’t return results as you’d expect?

It’d be exceedingly helpful if (assuming the text is non-sensitive), you could also share a line/paragraph that isn’t returned when it should be. That would really help in refining this further. Totally appreciate if that’s too much of an ask…

(Feel free to DM if that’s better.)

7

Thinking about this further…

By default, Drafts’ Quick Search searches for words in a search term individually, unless you surround the phrase with quote marks. So test drafts might return a wider range of results than "test drafts", because the latter looks only for occurrences of that exact phrase, whereas the former looks for any draft containing “test” and “drafts”.

This action acts like an exact phrase search, which might explain why you’re not seeing the same results. Let me know if that sounds about right, based on what you’re experiencing. If I’m right, I should update the description so that this distinction is made clear.

With the kind of filtering I was aiming for here, the exact phrase search style made more sense… that said, I’m sure it’s possible to do it differently… :wink:

8

New update: added an explanation for the kind of search this performs. Also added support for backlinks— the initial prompt offers the title of the current draft in two different forms as options for searching for linked and unlinked references.

If you checked out an earlier version of this, note that the most recent update also returns the full body of drafts containing the searched for term/phrase in the title. I may refine that further in the future— open to suggestions.

9

I installed the MGChecklistPrompt action group, then your Block level filter action. Drafts quick search gives the pictures results, but block level filter throws up an error saying no drafts were found with the query. I’m searching on “Carrie”

image
image1368×2732 115 KB

10

Thanks for following up! I see you’re in the “all” tab. The action is set to search “inbox” by default. Is there any possibility that these drafts are in your archive?

11

Update!

  • added another option: you can now set the filter options to search within your inbox, archive, flagged drafts or even trash
  • tidied up some sections of the code to make it easier to parse for people making their own adjustments (lots more could be done to tidy this up further!)
  • trapped an error that could be triggered by running the filter on a line containing an empty wiki-link
12

Update! Now with extra settings!

  • The first action step now allows you to control your preferences via the first action step (i.e. set ‘em and forget ‘em) or on the fly via the form.
  • If you manage your preferences in the action step you can set a few more options in the search scope (inbox, all, flagged, archive, trashed).
  • If you choose to manage your preferences on the fly, the filter prompt displays two switches to control whether the full text of a draft is displayed, and whether you want to search in the “inbox” or “all” scope.
13

I’m glad my uninformed question prompted such nice improvements to your action. Thanks for helping me out. I suppose I could’ve dipped into the code and noticed that it was only searching the inbox at the outset. :slight_smile: thanks

1 Like
14

Yep— I’m glad you asked! I think it’s a better action for the feedback it’s received…

1 Like
15

I know it feels like this has been dominating the forum lately, :relaxed: but I’ve got a minor bug and a suggestion.

First, the bug. The prefix to the date says “Modified”, whereas all your queries and the field you’re passing to the relative date function say"created" minor, but confused me a bit at first, :relaxed:.

And the thought. The big question was “what is the context if the search result is found in the title?” Rather than the whole Draft, maybe the first non-blank line would be better? That’d keep the amount of context similar to the original block search concept. So in other words, the next “block” after the title.

Honestly, for me it’s mostly academic, since if a search result turns up in the title it usually turns up somewhere else in the Draft as well, so I get plenty of context that way.

1 Like
16

Updates!

  • Fixed display of modified/created label.
  • Added option for sorting by modified or created date.
  • If the search returns a draft with the search result in the title, the first non-empty line of the draft is now shown as context, rather than nothing (if you haven’t set your preferences to show the full content of the draft). These lines are clearly labelled to avoid any misinterpretation/confusion.
  • Other small, cosmetic updates.

I think that’s everything? I’m a little snow-blind now! Let me know if anything doesn’t behave as expected…

17

Re-reading this it reminds me I wish we could do more with “paragraph mode” - including kicking off actions like this.

1 Like
18

Update! Fixed starting a search from another action (send the text/string you want to search for to this action from another action or from a shortcut; prefix incoming text as “fromWikiLink:”). Also fixed starting a search from selected text.

The first action step (preferences) now determines defaults for the way the action behaves (those defaults are used when searching in the above cases), but will be overwritten by options on the first prompt if that preference is enabled.

Does that sound as complicated as I think it does, having written those sentences out? :sweat_smile:

1 Like
19

Small update… All this block level thinking has made inline tags more useful for me. Not as an alternative to the existing tag system built into Drafts, I hasten to add, but as a complement. This update picks up any hash-tags in the line your cursor is currently on.

Wouldn’t take much to also pick up on “@” tags if anyone would find that useful. For anyone savvy enough to DIY, you’ll be looking for a regex in the third action step. :wink:

I’ve paired this with a slight adjustment to my syntax definition file that highlights inline hashtags…

{
      "match": "\\B#(\\d*[A-Za-z_]+\\w*)\\b(?!;)",
      "scope": "color.accent03",
      "exclusive": false,
      "comment": "Hash tags in text",
      "captures": {
        "0": {
          "scope": "color.accent06"
        },
		"1": {
          "scope": "color.accent06"
	   }
      }
    },

(…could probably be refined further, but I’m still getting my head around these syntax definition adjustments, and this works for me for now…)

2 Likes
20

I’m so glad you can spell “complement” @jsamlarose. Or rather use the right one. :slight_smile:

1 Like