Saved Searches in TP3


#1

Ideally TaskPaper would allow me to save search expressions within the app and access them quickly through either a menu or command key. I’d prefer this over relying on something like TextExpander. A great deal of power in TaskPaper comes from the search syntax and it’s a salient feature when compared with comparable task managers.

Using one of your documented FT examples, I’d love to see a preference for user specified search expressions such as /*//not @status complete[0] for next available action. Allow the user to name these search expressions so that even infrequent searches have a clear title for easy selection.


Date search operator suggestions
TaskPaper 3.0 Preview (149)
#2

Yes, I agree. I think this is important.

I also think non-power-users will not want to hop on the TP bandwagon if saving searches requires reliance on another app.


#3

Are there any other apps that have this same problem … i.e. they have complex searches and want to allow users to label them? I’d be interested to see some existing UI approaches.


#4

Just off the top of my head:

DEVONThink and DEVONAgent
BusyCal
iThoughts (called filters)
Mail and MailMate (usually called smart mailboxes)
Finder
PathFinder
TapForms
Feedbin and similar RSS reading apps and services
Taskmator on iOS

I’ll add this one caveat: The TP3 query syntax is much more complex and less memorable than most widget based search in those applications. It’s plain text and can include node level filters. It’s much less readable when scanning down a list of previous searches.


#5

I would love the ability to pin a saved search to the sidebar.


#6

Ok, I was thinking of a UI involving the search field… but a smart folder style UI would make a lot more sense and I think would be the right way to do it.


#7

I’ve been trying to think of how to implement smart folders.

My initial thought was to implement them as Mail.app does. Add a new section to the sidebar, new commands to add, edit, and delete smart folders. And associate each smart folder with a search path. I started messing with this approach, but it gets messy fairly quickly. To many new commands and UI required.

So my new thought is to just embed smart folders into the existing plain text syntax. There’s already the convention of projects showing up and being clickable in the sidebar. I think smart folders can be handled in a similar fashion. I think we need some convention for associating a search with a project. And when a project has a search associated with it clicking the project will set the search?

Thoughts?


#8

That’s a really interesting idea. Similar to the file link option where you must click the link to filter? Or were you thinking that a separate plain text file will just store the definitions for the filters but they show up in the sidebar? The really boost will be associating the most used filters with keyboard commands, so consider that in your design.


#9

The idea is to embed searches in your document, not in a separate config file.

Somewhat similar to how FoldingText allows you to embed searches in URLs. Similar because with both approaches you embed the searches in your document. But improves upon the embedded URL approach in the following ways:

  1. First TaskPaper has a sidebar. So just TaskPaper now searches your document for projects and displays them in the sidebar… it can do the same thing for searches. So you’ll be able to access your searches quickly, instead of needing to navigate through your document looking for a link.

  2. Second I will use a new syntax for defining searches instead of embedding them in URLs. The problem with URLs is the search syntax needs to be escaped making them difficult to read and edit after the’ve been encoded as the URL.

The question is how to embed these searches in the document if not encoding as URLs. Some options include:

  1. Use tags… so any line that contains @smartfolder(type your search here) gets displayed in the sidebar, and when clicked it sets your search.

  2. Define a new item type syntax, so TaskPaper would then have (projects, tasks, searches, and notes). I think I prefer this option… embedding in tags seems messy. The final syntax needs to include a label part and a query part. Here are some possible syntaxes:

    • ? My Search: @a and @b//*

    • My Search:: @a and @b//*

At the moment I like the leading question mark syntax. If anyone can think of something better let me know soon! :smile:


#10

Rather than inventing a new markup syntax, how about using the Multimarkdown definition list syntax? As a user I could then include that anywhere and it also provides plenty of readability.

Apple
:   Pomaceous fruit of plants of the genus Malus in 
    the family Rosaceae.

    Also the makers of really great products.

#11

That could work, but it becomes harder to parse and map to my outline model. Instead of just one new type of “search” item we’ve got two: “term” items, and “label” items. Also the parsing becomes harder, because the type of one line depends on another line so the parser needs to do some forward and backward scanning. Single line syntaxes fit much better into TaskPaper… avoids much of the parsing complexity that FoldingText has.


#12

I don’t have a strong preference but I wouldn’t want it to conflict with the syntax for projects supported in other applications. Seems like both of the proposed formats would be interpreted as a project name.


#13

I don’t think my proposed syntaxes “should” be a problem in that respect. A project should only be recognized if there’s no text after the “:”. Otherwise anytime you use a colon in your notes it would turn into a project. I guess do let me know if you see another TaskPaper reader struggle with that… I haven’t kept careful track of what’s out there.


#14

Hmm. I know you’re the father of the syntax so I’m not going to argue but tags after colons are supported in Taskmator and PlainTasks for Sublime Text. Could just be a happy accident.


#15

No you are right, I’d forgot that bit! What about:

? My Search ? @a and @b//*

#16

I have no major complaint with that other than hard to recognize when scanning a document. Might be prime for mistakes with all the white space requirements so support something like this too:

?My Search?@a and @b//*


#17

Hum… I agree again, without syntax highlighting those question marks blend it pretty good. I like the idea of using a question mark in the syntax since it seems to be a good match for running a query. Here’s a new list of ideas:

  • Do Next Week [?] @due >[d] today and @due <[d] end of next week
  • Do Next Week ?? @due >[d] today and @due <[d] end of next week
  • Do Next Week -?- @due >[d] today and @due <[d] end of next week
  • Do Next Week :? @due >[d] today and @due <[d] end of next week

Any preferences? I sorta like :? as I can make it mean “defining a query” in my head. Though it probably sticks out the least visually.


#18

Not a fan of starting without some anchor text or characters. If we break it down, there’s a name and a parameter part. You currently have syntax for tags with parameters like so:

@due(2015-11-11)

Extrapolate a bit without conflicting too much with Markdown:

##Do Next Week(@due >[d] today and @due <[d] end of next week)

That would also stand out a bit better too. It would look like a header with Markdown parsing so I don’t think it’s too terrible.

I’d even be good with @@Do Next Week(@due >[d] today and @due <[d] end of next week) but that might make parsing harder but it is supported with other apps (not recognized as a valid tag).

That seems more inline with Taskpaper format since it resembles the tag/attribute relationship.


Posts moved from TaskPaper extensions Wiki
#19

As far as I can tell curly braces are not yet used in TaskPaper (or Markdown). What about this syntax:

Do Next Week: {@due >[d] today and @due <[d] end of next week}

I could not find out with 100% certainty whether you allow tags after projects lines, or whether they strictly must end with the colon, so this syntax extension might be problematic for the parser.

But I must say I like its unobtrusiveness. The curly braces are a good hint in my opinion that something is evaluated here (compared to the static metadata in @tags) and it makes sense to attach the curly braces block to a project line, since it will usually return more than one item, and saved searches might appear in the side bar in a similar way that projects do.


#20

Thought I’d pitch in with my 2 cents.

The @ symbol is associated with a tag so @tag makes sense. Why not extrapolate that to queries. ? symbol is associate with queries, so in my mind, ?My Search(@due >[d] today and @due <[d] end of next week) would make perfect sense, or if we need to make it stand out a little more, simply use ??My Search(@due >[d] today and @due <[d] end of next week)