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…
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:
Find any project that contains the text “Inbox”
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!
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 . 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:
@progress and @progress//*
Reads as:
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.
For each of the matches in 1. match all descendants.