GothenburgBitFactory
FR Allow filtering by context / for tags to be defined in terms of other tags
Currently, tags have single values, we do not have hierarchical tags (see #2038) and some pattern matching is currently not ideal (see #1720 - though I haven't tested this much myself). (I am not sure that hierarchical tags are actually desirable, personally, but that is not the current issue...)
You can get around this to an extent by setting contexts which take a set of filters. This is nice, but currently, if you want to search for tasks matching some subset of tasks with regularity you have three choices:
- manually create something with your interactive shell's aliasing or abbreviation features. Fish now allowing abbreviations to match depending on the rest of the arguments (and there is a zsh plugin for the same thing), this is quite easy to do and allows you to easily set up some abbreviation to match for a subset of tasks, however there is the obvious downside here that this is a shell-generic feature and not a taskwarrior one.
- you can set a context, and then manually switch every time.
- ẏou can write some hooks that parse task tags and set them in some UDA and then filter based on the contents of that UDA. I feel this is the most clunky and worst option.
(2) leads to a lot of unnecessary typing. This FR suggests adding a novel filter for contexts, so you can search tasks within contexts with a context: filter. This would also allow more powerful searching, as you would be able to combine context filters.
A secondary proposal, or an alternative way of handling this, would be to allow us to set arbitrary tags explicitly as a combination of other tags/filters via a configuration file option. Something like tag.foo=+bar +fee. This would seem to encroach on the territory of contexts quite a bit, but as someone who really only uses contexts as 'saved searches' and not so much as 'I will only look at XYZ for the next 4 hours,' I have to confess I find this syntax more intuitive. This has the same benefits as the previous idea in terms of allowing more combinatory filtering.
If either of these are adopted there is a question about how contradictory nested filters should be resolved. Should you just receive no matches? Should some take priority in some way? Should there simply be an message detailing the contradiction. If there is such a message, I think it would be ideal that there be an interactive way to 'correct' the contradiction on the fly.
I'm curious why you can't just use custom reports for this? E.g., I have a today report that filters for +today, so I just run task today to show that report.
I had overlooked/forgot about report customization, thank you. I'll start using it!
Still, there are a few downsides to reports:
- you have to write them to the config file (it's easy enough to write a wrapper to do that quickly) - this is great if you want to keep the same thing around for a while, not so great if you frequently change it or are changing it several times in quick succession.
- you cannot modify them on-the-fly. a wrapper can handle this too, especially if you're just doing report=<some filter> -> report=<some other filter>, but it's a bit harder to implement something like report=<some filter> -> report=<some filter +filter -filter> -> report=<resulting filter>.
- you cannot combine them (on-the-fly) with AND/OR/NOT operators. A wrapper can likely handle this using regex and sed/grep/etc., but for this one, I think (1) in my last comment has the clear advantage. (In fish it's quite easy to pair some regex pattern of +<tagname> to a visual expansion of +tag1 +tag2; in bash you'd have to write a function to do it).
I have been using 1 (with some other stuff to allow for easy modification of my abbreviations), but I wrote in the suggestion because I felt like it might be something other people would be interested in. I'll write something to quickly save common combinations made interactively via 1 to reports (or maybe just more abbreviations; I appreciate the visual expansion...)
Given some thought, hierarchical tags would allow rough replication of this most of the time, so I think that ought to take priority (given it is already requested as well).
I would be willing to see if I can hack together something PR worthy, but I am not experienced with C++/rust so I don't know how that will go. I also wrote partly to test the waters for interest/thoughts on implementation details. I should probably have opened a discussion instead of an issue - I wasn't sure where FRs are preferred on this repo (different projects have different implicit guidelines).
My most frequent use-case for this personally, at least recently, is for running queries in TW through my pile of papers/textbooks-to-(re)read (which has made a gradual migration from text files and a zotero collection to TW) to allow for easy manipulation (take all this stuff and make it depend on y for example), and it's gradually replaced some combination of hierarchical projects + tags.
(I'm also using this to regularly query already-read stuff via completed tasks... but arguably this is 'not the right tool for that' and I could do with fuzzy searches in such instances, as well...)