inconsistencies when merging context with filter provided as argument (OR vs AND)

[Dieterbe]

When you have a context set in the statefile, and you also specify a filter when doing dstask next I notice that

• project is OR-ed (task that have either project from context or filter, are returned)
• antiproject is OR-red (task that has any of the mentioned projects, is filtered out)
• tag is AND-ed (task must have all tags provided in both context and filter, to be returned)
• antitag is OR-ed (task that has any of the tags specified, is filtered out)

this inconsistency between AND'ing and OR'ring seems a bit strange.

[naggie]

When you have a context set in the statefile, and you also specify a filter when doing dstask next I notice that

* project is OR-ed (task that have either project from context or filter, are returned)

This appears to be a bug introduced by https://github.com/naggie/dstask/pull/53 or https://github.com/naggie/dstask/pull/43 -- v0.20 works as expected. We'll have to fix that and add a regression test.

* antiproject is OR-red (task that has any of the mentioned projects, is filtered out)

So -project:foo does not show any tasks from project foo? That's expected. Did I understand it wrong?

* tag is AND-ed (task must have all tags provided in both context and filter, to be returned)

Yes, expected.

* antitag is OR-ed (task that has any of the tags specified, is filtered out)

Expected again.

this inconsistency between AND'ing and OR'ring seems a bit strange.

Does it make more sense if the first one is corrected?

[Dieterbe]

So -project:foo does not show any tasks from project foo? That's expected. Did I understand it wrong?

that's right but also kind of obvious what should happen if there's only a single antitag. my point is about if you have multiple antitags specified. e.g. -project:foo -project:bar (possibly specified by both cmdLine and context) then this condition gets ORred, not ANDed. I don't have a strong opinion on whether the condition should be AND or OR (actually OR, as it is, seems quite sensible), my main issue is more about the inconsistency across all of it.

So you're suggesting

• project AND (is currently OR)
• anti-project OR (as is)
• tag AND (as is)
• antitag OR (as is)

at least that would be more consistent that the positive things are ANDed and the negative ones are ORred. While seemingly inconsistent, it's not too hard of a rule/pattern to be mindful of. Note that having >1 project conditions getting ANDed can never match anything, as a task can only have one project assigned, so OR actually does make sense, but then tag search should also be OR.

For tag search specifically, both OR and AND seem useful

[naggie]

Note that having >1 project conditions getting ANDed can never match anything, as a task can only have one project assigned

That's right. The parser matches the last one specified only. Since the filtering changes, the filtering accepts both rather than a single merged context which is a side affect of @dontlaugh's filtering implementation. I will update the project matching filter.

@dontlaugh could you invite me to the slack channel? I'd like to discuss taskSetOps with you, as I have a few questions

[dontlaugh]

@naggie are you in the gopher slack? it's the #dstask channel. It should be public, iiuc

https://gophers.slack.com/messages/general/

[naggie]

I'm not, couldn't register as far as I can see, is there a registration link or something?

[naggie]

Btw both-- I updated the filter to match projects, I'll try to add a unit test tonight

[dontlaugh]

try this https://gophers.slack.com/join/shared_invite/zt-ix30fo90-WPv70bc4ajk66GHYZnCLag#/

[naggie]

Great, that worked. Thanks

[naggie]

From slack:

I think the AND based querying for projects aligns with the common use cases. I can't think of a reason why I'd want to see multiple projects at once, project querying allows me to focus. I'd like to avoid supporting configurable logic as then we go down the path of implementing a whole DSL as for little or no benefit.

[dontlaugh]

Is this issue being actively worked on?

[Dieterbe]

no. i think we have to agree on what the desired behavior is and then any needed changes should be easy. i'm not in the right headspace right now, but can look into it later. meanwhile i'm curious for your thoughts @dontlaugh

[naggie]

The current (master) behaviour represents what I think is "right". I think it's just a case of me documenting what we currently have, and then we can discuss it to see if changes are necessary