Filtering with projects and tags

Is it possible?

I’d like to set up some filters using tags but specific to work projects.

I’m sure it’s possible, I’m just not grokking the new syntax for some reason…

So you want to search for a tag, but only within a specific project?

To do that you could do:

project Inbox//@tag

That says:

  1. Find any project that contains the text “Inbox”

  2. Match all descendants that match @tag.

Not sure if this will help, but here’s the expanded form (no shortcuts) of the above search:

//@type = project and @text contains Inbox//@tag

No docs is a pretty good reason! :smile:

2 Likes

Definitely seems like project contains "Inbox" would be a super handy shortcut syntax for the filters and search.

Maybe I don’t understand you, but that should already be working. project contains "Inbox" will match any item that is a project and whose body text contains the string “Inbox”. Though since contains is the default test you can just leave it out and do project Inbox for the same results.

Also project is just syntax sugar for @type = project and .

Sorry. I really meant project contains as an attribute of a task. Meaning show all tasks (and project name) in any project that contains a string. For example, this query should show one task:

project contains "schematics" and @today

For this outline:

Ahh I see what you mean… and that is the way that TaskPaper 2 queries worked. But I don’t think it fits into the TaskPaper 3 query model very well. In TaskPaper 3 when you want to start talking about the item hierarchy you need to use some sort of path operator to describe what part of the outline you want to search.

The TaskPaper 3 way to perform that search is actually shorter, but maybe less user friendly:

project Schematics//@today

Does that get the results you wanted?

TaskPaper 2 items all had a “project” attribute so that hierarchical queries could be made even though the query language and evaluator didn’t understand hierarchies. In the TaskPaper 3 model the query language does understand queries and so items no longer have a build in “project” attribute.

That syntax doesn’t seem to work

It seems to work for me. Here’s my example outline:

Project 1:
	- task 1 @done
	- task 2
	- task 3
Schematics:
	- task 1 @today
	- task 2 @done
	- task 3
	
@search(project Schematics//@today)

When I click the search I see only “task 1” of the Schematics project.

Here’s some screenshots. Here’s the outline again:

Here’s a query that does work:

Here’s the one that does not work:

I’ve tried with and without a space. Also tried capitalized and exact project name.

Derp. Just realized the syntax I have is wrong. I really DO prefer the TP syntax. Sorry.

project Schematics//@today works.

Following this thread (not sure if creating a new one was necessary), I was wondering how to display all the tasks under a project that are tagged with @progress and all the other tasks that are in @progress. In that way I can just include all the tasks under that project without having to spend a considerable amount of time tagging everything under. I did figure out that doing the following would give me the projects with the tag, but it would not include the rest of the tasks.

In another words. I can get the tasks in @progress

@progress

Or I can get the projects in progress and all their children

//@progress/*

But not both. Am I missing something?

I’m pretty sure the answer is yes… but I’m not quite sure I’m parsing the question correctly :smile:. If this search doesn’t work please give me an example outline and what you would like to see.

@progress//*

This search says find all items tagged with progress @progress and then starting at those matching items find all items indented under them \\*. If you wanted to scope this to a particular project you could do something like:

project Inbox//@progress//*

All of these searches are only “matching” the items indented under @progress. But since TaskPaper always shows the ancestors of each match the project and items tagged @progress are also displayed. If you really need to match all those items you can always combine paths using union, intersect, and except as described here.

Thank you very much for the link to the documentation. Things make more sense after reading your documents.

Yes, what I was missing was the union operator. I was using and and I was not getting anything back. I am still not sure what is the difference between and vs union or where to use either. To summarize. I am not sure why

@progress union @progress//*

Works, but the following doesn’t.

@progress and @progress//*

Should I just start using union instead of and?

and works at the predicate level (combining attribute tests on a single item while union combines the all results of two separate node paths.

@progress union @progress//*

Reads as:

  1. Search all items for items that contain the @progress tag.
  2. Search all items for items that contain the @progress tag, and then return all descendants of those items.
  3. Combine the results of 1. and 2.
@progress and @progress//*

Reads as:

  1. Search all items that have @progress tag and that have @progress tag. (Should work, but you could leave out the “and @progress” and get the same result.

  2. For each of the matches in 1. match all descendants.

1 Like