Saved search context?

TP 3.3.1 on OSX 10.11.5.

I have 5 projects in a file. I choose one of the projects in the sidebar. I then do Shift-Cmd-F to search, and type “not done”. TP then filters to only show the tasks in that project that are not done.

I do the same steps, i.e. choose the same project on the sidebar, but this time choose a “Saved Search” in the sidebar that does the exact same “not done” search (@search(not @done)). However, the saved search searches across projects, and shows me all of the tasks in all of the projects in the file that aren’t done, not just the ones in the currently selected project.

Can we have saved searches “know” the context? IOW, a saved search that is as smart as Shift-Cmd-F? There should probably be a search option to tell it to search all projects regardless of the current context, but IMO the default should be the current context.


1 Like

I don’t use saved searches, so I’m not sure if this will help, but I think you could just save your search as

project [PROJECT NAME]//not @done

so for example:

project Inbox//not @done

ETA: Just tried it out myself and it doesn’t seem to work with the saved search syntax. Sorry about that!

Thanks, but even if it did, it’s not really what I’m looking for. I want the saved search to be aware of context, not have to put context into it. The search bar knows the context, and executes its searches against the current context. I want saved searches to do that by default, with possibly a way to override that and specify the whole file instead of just the current context.

This decision is based on how side effect of how saved searches are displayed in the sidebar. In the current setup (where the selected in item in the sidebar is “displayed” in the content view) I think the current behavior makes the most sense.

With that said I agree it’s not necessarily optimal, though I don’t yet have an alternative design in mind. Some possibilities:

  • Don’t show saved searches in sidebar, just show in search field menu.
  • Allow multiple selection in sidebar (so both current search and current project can be represented). I don’t really like that as a solution, but it demonstrates the problem.

Other possibilities?

I guess the first two things that come to mind are:

  1. If your set of projects is stable, full search paths which include the project name as well as @done or (not @done)
  2. or a script along the lines below, which offers a menu of the @searches in the document, and applies them with the name of any focused item (e.g. focused project) prepended

// Ver 0.03

(function () {
    'use strict';


    function contextualSearches(editor) {

        var itemFocused = editor.focusedItem;

        return editor.outline.evaluateItemPath('//@search')
            .reduce(function (a, item) {
                var strSearch = item.getAttribute('data-search');

                return (
                    strSearch && (
                        a[item.bodyContentString] = strSearch

            }, {})


    function applyFilter(editor, options) {
        var strFilter = options.filter || '';

        editor.itemPathFilter = strFilter;


    var tp3 = Application('com.hogbaysoftware.TaskPaper3'),
        ds = tp3.documents,
        d = ds.length ? ds[0] : (
            ds.push(tp3.Document()), ds[0]

    var dctSearches = d.evaluate({
            script: contextualSearches.toString()
        lstSearches = Object.keys(dctSearches),
        lngSearches = lstSearches.length;

    if (lngSearches) {
        var a = Application('System Events'),
            sa = (a.includeStandardAdditions = true, a),

            varChoice = lngSearches > 1 ? (
                sa.chooseFromList(lstSearches, {
                    withTitle: dctSearches.focusItem || 'Whole document',
                    withPrompt: 'Filter:',
                    defaultItems: lstSearches[0],
                    okButtonName: 'OK',
                    cancelButtonName: 'Cancel',
                    multipleSelectionsAllowed: false,
                    emptySelectionAllowed: true
            ) : lstSearches;

        if (varChoice && varChoice.length) {

                script: applyFilter.toString(),
                withOptions: {
                    filter: dctSearches[varChoice[0]]


Tho on second thoughts it might be better to define the context in terms of the project containing the cursor …

( also straightforward, I think )

You already know where I’ll land. :slight_smile:

To me, the fact the searches are in the sidebar is a visual detail, not an implementation detail. IOW, the fact they’re in the sidebar doesn’t imply anything about their context. That’s just the most handy place to display them. (One I’m fine with, BTW.) It never occurred to me otherwise, honestly.

I expected those searches to mimic what I would do manually in the search bar. That’s what they are — searches I do manually a lot, so want to save. Why would we want saved searches to have a different behavior than our manual searches? That defeats the whole purpose of saving the search in the first place.

With the current implementation, a saved search does me no good. I never (within two decimals of never) want to search the entire file. I want to search my current project. (I admit, this is mostly because I haven’t discovered an efficient way to handle in TP what I want to do today. If I was a better administrator, I would go through all my various projects every morning and mark the things I want to do today with @today and unmark the things I marked yesterday that didn’t get done and that I don’t want to do today, and then I would have a saved search for Today, and I would want that one search to be against the entire context. But the solution for that is @searchall for that one search, not forcing every saved search to be against the entire file.)

So, I’m firmly in the camp that a saved search should do exactly what the equivalent search typed into the search bar would do with respect to context. This lets us do whatever we want with a saved search — we can search everything by setting the context appropriately, or we can search a single project by setting the context appropriately.

Now, if the current context is a single project, then I would agree that showing that on the sidebar would be nice. Currently, selecting a saved search highlights the saved search and de-highlights everything else. If the context was the current project, then showing a de-selected highlight on the project that was the context would be good. So, today, if I click on a saved search it goes blue. If I then click back in the file, then the saved search shows (in my theme) a soft grey. So, the implemention would do something like that — clicking on the saved search would make it blue and the project grey. Clicking back in the file would make the project blue and the saved search grey (because now the project was selected and the saved search was de-selected). That sounds a lot more complicated in print that it would appear in TP. :slight_smile:

If you want to be magnanimous and give us a syntactical way of saving a search that always searches the entire file (@searchall, e.g.), then that would be extra awesome. But we don’t need that — we can search the entire file by setting the context to the entire file. (Don’t get me wrong, I’m all for something like @searchall, it’s just that respecting the context is a much higher priority. For me.)

That might work, though it makes the logic/code in the sidebar a bit more complex. Eventually I expect a sidebar update… it has other problems too like dealing with lots and lots of projects. I think I’d likely try to solve this problem at the same time as that one.

In the meantime @complexpoint’s script can get you pretty far I think… the one that pops up all of your saved searches and allows you to choose which to apply.

Updated to draft 0.02 above:

  • Better emulation of ⌘⇧F behavior – preserves focus for alternate searches/filters afterwards
  • skips menu if the document only has one saved @search

Updated to draft 0.03 above:

  • menu displays search titles rather than item paths

1 Like