Theme: Tomorrow Night Eighties inspired theme [dark/light] with Omnifocus-like searches/tags

That would be “ordered list” (1,2,3,…) and “unordered list” (hyphens).

Thanks, but which differencd would this make under the given context of GTD type filtering? I put together a couple of identical projects and tagged those with

  1. @ol
  2. @ul
  3. status(active)
  4. none of those.
  5. combinations of 1, 2 and 3

I could not figure out a single filter with a difference for the use of @ol and @ul.

What am I missing here?

I am assuming that there are tasks that are sequential and others in which the order they are accomplished is irrelevant. For example.

Paint Car:
	- Clean. @ol
	- Sand. @ol
	- Prep. @ol

Buy Stuff:
	- Tamales. @ul
	- Power drill. @ul
	- Flame thrower. @ul

Or even,

Paint Car: @ol
	- Clean.
	- Sand.
	- Prep.

Buy Stuff: @ul
	- Tamales.
	- Power drill.
	- Flame thrower.

Good question, sorry for late reply!

@ol => Ordered List
@ul => Unordered List

I use them at the project level (project = list of tasks). It helps me remember if the tasks listed under a project are to be completed in order or not so that I don’t have to ask myself that question later.

I don’t use them to “filter” by contexts. I use them as visual a “helper” contexts during review or when I take actions. It may not be GTD compliant but it really helps me, especially when I have lots of projects to go through and/or review.

The most valuable argument to use these contexts is that… It works for me. :slight_smile:

I opened up an old list file. Here are 2 examples where I used @ol and @ul at the project level:

Thanks! That makes a lot of sense and explains why I could not find any actual result difference when applying your different filter views with and with ol and ul at the projects - because @ol and @ul are simply applied in the brain of the user! “You must do these in order - don’t think about task 3 before finsihing one and two!”

Your setup helps me a lot in streamlining the way I use taskpaper - thanks so much for all the work you put into it and making it available for the community here!

Bsst
Torsten

Speaking of ordered vs. unorderen projects/tasks and OmniFocus-like searches: Here is a hint, which makes it possible to mimic the OmniFocus behaviour for sequential and parallel projects. Hope someone will find it useful.

1 Like

Dmtry,

I had forgotten about that already. It is a really good search. I will add it to my Quiver’s notebook. Would it be possible to do one more edit to your example and add parenthesis? I find that people really struggle to understand complex queries if they are missing them. Thank you for the example and the reminder!

HAPPY THANKSGIVING Y’ALL!!!

Actually there is nothing complicated in this search. No parentheses are required. If you break it down, it basically says:

  1. @seq//not @done[0] — In each sequential item choose only first undone child item

  2. union not @seq//not @done — combine them with all undone children of parallel items

  3. intersect @type=task — among them all select only tasks (adapt this part or omit it entirely)

  4. except @done//* — and eliminate all children of done items

Here the complete search:

@seq//not @done[0] union not @seq//not @done intersect @type=task except @done//*

Of course you can further improve this search to meet your specific needs.

I have a question: Why are all of the searches set to @type = project? That never returns anything for me. If I edit your searches to change that to @type = task I seem to get meaningful results. I say “seem to” because I am confused by a bunch of your other syntax (for example, your use of \ confuses the hell out of me, and I can’t find it in the docs at all), but this is the one thing I’m pretty sure is breaking every single search for me.

It matches “project” items, those that end with a colon, such as:

My Project:

In the default “Welcome” document searching for @type = project should filter the list to only show:

Welcome:
To Create Items:
To Organize Items:
To Fold, Focus, and Filter Items:

The full search documentation is at:

https://guide.taskpaper.com/reference/searches/

Generally / can be thought of as a filesystem path divider. Look in the search documentation for the “Item Paths” section, and then for “Steps” each of which is separated with a /.

It matches “project” items, those that end with a colon, such as:

Right, I get that. But all of the searches are for things like not @done which apply to tasks and not projects.

The full search documentation is at:

Searches · TaskPaper User's Guide

Generally / can be thought of as a filesystem path divider. Look in the search documentation for the “Item Paths” section, and then for “Steps” each of which is separated with a /.

Right. My issue is with \ , not /. Which is not mentioned at all in the search syntax reference but I finally happened to dig up here that backslashes are used to escape parenthesis in some way that doesn’t seem to be documented outside that one forum post.

Not necessarily, using “projects” on your queries would depend quite a bit on your workflow and what you want to show or hide. For example, I don’t want to see projects if they are empty or that only have children that have certain tag that I am trying to hide; so I use something like,

except //@private/..* union @private///*

Now, that would only hide all the elements and their children if they are tagged with @private, but it would also hide those projects or tags, or notes, that only have children that are tagged with @private.

Just write that part of the query somewhere and use it as you need it. If you never use it, then no worries; but if you use it often, then you start to figure out things little by little. You can ask about queries and people are usually very friendly and tend to help.

It was an element of the early iterations of TaskPaper. At one point there was no way to save searches in your documents, and when that was added, it was necessary to escape the parenthesis as you manually entered your query in the document. Now it is not necessary to know that since the newer versions of TaskPaper do the escaping automatically when you use TaskPaper to create and edit your searches or queries.

AHA! That’s the missing piece for that one. So, you’re saying I could delete all of the \ from these searches and it would be functionally equivalent on a modern version of taskpaper?

[EDIT: took out “your” searches, forgot who I was addressing :slight_smile: ]

It is not necessary to escape all the parenthesis if you use TaskPaper and the easy search editor included in it; but since the beauty of TaskPaper is that you have files that are agnostic, your actual search will include those escapes in the file (the search editor will add those for you!). So what I am trying to say is that it is recommended for you to use the options within TaskPaper to edit and create new searches.

So… yeah. You don’t have to escape every parenthesis if you are using TaskPaper to create, or edit your searches. But if you go with another editor or you go to the actual code within TaskPaper; and you want to modify the queries, you will have to escape those there!

Hope this helps. Somehow the bold seems kind of aggressive, but that is far from the tone. I just want to make sure you get that distinction. I am still not sure if I was clear or not. Play around with the file and if you still don’t understand, post another question.

1 Like

No. Leave those alone. Hahaha.

They are there for the parser. Just learn to ignore them and try to use the sidebar instead since it is more convenient and easier to understand. The search editor there will translate everything hiding those escapes automatically or adding them for you. You will never see them unless you look at the actual search on the source.

(hey, I figured out how to actually quote. Sorry about that!)

Ok, let me be more concrete in what I’m saying. One of the included searches is

All Metadata & Tasks @search(//@type = project and \(@status = active or @status = ongoing or @status = hold\)//* and not @done)

And another is

All Tasks @search(//@type = project and \(@status = active or @status = ongoing or @status = hold\)//@type = task and not @done union //@type = task and not @done/*)

I had been working under the assumption that I was getting no results from either because it was trying to return a Project that was also a Task. From what I’m understanding in this conversation, this search actually means “return the results but also return the project name that each result falls under”.

If that is true, I still don’t understand why “All Metadata and Tasks” returns nothing, and “All Tasks” returns only every task in my inbox project, and not any other task at all. And, no other search included in the example searches returns anything at all.

I think you’re missing the thing I’m trying to accomplish here: this theme comes with a searches.taskpaper file and I am trying to get any of them to work :slight_smile:

1 Like

Ohhh… Now I am following you. Yeah, you are looking at the searches from the search file itself and then you are trying to figure how it works by reading them the searches. Honestly, I think it is going to be a little bit hard to do it unless you have a populated documents with lots of data because there is a lot of logical into this workflow. It is a lot easier if you have some documents with info that you can use to play around and try things to figure out things.

Let me unpack the first search you asked for,

//@type = project and (@status = active or @status = ongoing or @status = hold)//* and not @done

First, notice that I eliminated the escapes, because that is just for the parser. Like I said before, I usually just look at the sidebar and do the creations of searches or the modification of them from there. Now, let’s split this in concise chunks.

  1. //@type = project
  2. (@status = active or @status = ongoing or @status = hold)//*
  3. not @done

I don’t understand the philosophy behind this particular workflow, but this one is only looking at children of projects that are tagged with a particular value. Those tags are, @status(active), @status(ongoing), and @status(hold). I know that is looking for the children of those projects because it enclosed the second in a parenthesis and then it has the //* path that is telling TaskPaper to include all of the children of those tags that are also projects (that is step 1 & 2). Finally, it also wants to make sure that it ignores those that are @done

I honestly don’t understand the title of that query, All Metadata & Tasks, because I don’t understand the idea behind the system. Since it is not looking at all the Metadata and Tasks, but just the metadata and tasks of the projects that are tagged as I mentioned above; I think that if you want to use this, you need to tag all of your projects with one of the three tags there. Again, this is just an inference!

Now, unto the next one,

//@type = project and (@status = active or @status = ongoing or @status = hold)//@type = task and not @done union //@type = task and not @done/*

I think that that particular query needs more parenthesis. Hahaha. I honestly think that there is some redundancy in the query, but I need to spend some time trying to figure out why it was constructed that way. Let me get back to you on Monday.

@drootz Nice theme, but I think it’s broken in 3.8.6. :frowning: