Tinderbox has very efficient fast autocomplete for String- and Number-type fields shown as Key Attributes. What action are you carrying out that you're assuming should result in a list of fields.

Do bear in mind Tinderbox is not a specific task management app, unlike seems to be the case of OmniFocus (which I've not seen or used). You can use it just for to-do lists but you'll need to do a bit of set-up first. If you can describe the process, likely fellow users here can help you configure your TBX accordingly.

edit: typos.

Okay I made a little example tinderbox for the process I outlined above.

It works even better than I expected – it lets me automatically create projects on the fly just by typing in a previously unrecognized ProjectName!

And perhaps the most fun part of the whole thing was documenting it in Tinderbox itself. Pretty neat

edit: Fixed the mistakes that Mark A points out below

Have you thought about using the Attribute Browser to look at your projects?  

If you have a set attribute $Project whose values might include "Chores", "Errands", "Urgent", "Home Repairs", and "Campaigning", then an attribute browser could show all the errands when you're out, or all the repairs when you're home.

Quote:


Thanks for catching that!

Quote:


Yay I didn't know how to reset to an inherited attribute. Now I do!

Quote:


This is very cool. I didn't expect something like that to work, but now that I look at it I see why it would. I created another version of this tinderbox that manages the workflow entirely via stamps – no agents or rules involved at all.

Quote:


Yeah I don't adhere strictly to GTD at all... which is part of the reason I want to move away from OmniFocus. It is REALLY nice software (some of the best Mac software I've ever used) but there are certain tweaks I want to make to my process that it doesn't support very easily. Plus its note-taking abilities are nothing compared to Tinderbox – though to be fair, I don't think ANY other software compares to TB in that sense.

Anyway... recurring tasks are an interesting case. There are three kinds of recurring tasks I've identified:

* ones that occur (nearly) every day – think morning routine, or daily responsibilities
* ones that occur on specific day(s) – taking out the trash
* ones that I want to become available at certain intervals

The first one I handle with a prototype. I have a "p_daily_todo" prototype which represents a TODO list for that day, and includes all of the tasks that I would ordinarily work on in a single day. These get bequeathed every time I make a new note inheriting from that prototype. Super useful.

I actually haven't done the second one yet, but it'll be similar. I'll add a "TODAY" note to my p_daily_todo prototype. Then when I make a new todo list for that day, I'll choose a "p_todo_tuesday" prototype to pull in the tasks for Tuesday. Move those tasks into the main todo list and delete that placeholder...

The third is pretty interesting. In that case, I think that I'll have an agent which looks to see if a $TaskDoneAt is beyond a $RecurringInterval and if so remove the $TaskDoneAt or something.

I'm already getting a lot of mileage from my basic todo list stuff, so adding project notions will be a big step up. Recurring stuff can be down the road...

Quote:


I had not! I actually had not ever used attribute browser before. But it looks pretty nifty. It actually does exactly what I want in this case. A GTD concept that I use regularly is Contexts – so I'd have stuff like "Phone", "Office", "Home" etc... with this, I can set a query to find the notes that I want, and group by context or project depending on how I want to look at it.

What would be really amazing would be to save a specific "view" like this. So I can easily switch between views of the tasks organized by project and by context, or have multiple queries.

Quote:


Yep that works really nicely with contexts, which I want to be available even if there are not pending tasks matching that context. The projects list on the other hand should change as I complete them.

Thanks for the input, guys! I learned a lot here, and have some new ideas to make it even better. Glad I posted

You can easily save a specific attribute browser view as its own tab!

Quote:


The way I deal with this is:

• Both for GTD purposes and for article-research files, I usually create two or three separate windows for the file. There was a time, many betas ago, when the layout of multi-window files was fragile, and after a crash you'd end up with only one window left. It's much more robust now, and I haven't had that problem in a long time. Still, it's worth saving a backup of the file when you have a multi-window layout you're happy with. Then if your windows ever disappear, you can recreate them by splicing in the XML. (Separate topic, details if needed).
• I usually devote one of these windows to a whole set of Attribute Browser tabs. If it's a GTD file, one of the tabs will be by Content; one by Due Date (or Done status); one by Project Name; etc. For a research file, one tab might be AttribBr organized by Source; one by Theme; one by fact-checking status; one by something else. The window that I devote to these AttrBr tabs might have anywhere from three to eight tabs, depending how many ways I want to see the info.
• My other windows are organized in whatever way I want.
• These tabs do persist from session to session, so once you have set them up they'll be there.

The Attribute Browser was added to the program in Version 6 and, for me, is a gigantic step forward in usefulness. Main point, again, is that once you set up a series of tabs, they will be there.