Filter combination (OR)

[ncarboni]

It would quite useful to have the possibility to combine filters with OR, in order to have query such as

give me all the task that

path includes x
description includes #x

Right now it is possible only having two "task query":

tasks
       not done
	path includes x

tasks
	not done
	description includes #x	

But it is a bit annoying to have the task counter below each "task query" instead of a sum of both.

A solution would be to use AND as default, and only OR when necessary

tasks
       not done
       path includes x
       OR
       description includes #x	

[schemar]

It would be nice, indeed. Would also require parentheses to group statements.

[Masstronaut]

+1 to this!

Here's an example from my Eisenhower Matrix built on Tasks, which grabs all tasks that are:

• P0 or P1
• overdue or due this week

```tasks
not done
description includes #P
description does not include #P2 
description does not include #P3
due before next week
```

Because the filters are implicitly AND operations, something which would be a trivial inclusive OR requires a broad filter and narrow filters that exclude what I don't want. You can imagine how this could become extremely tedious and error prone if I had something with many options such as P0-P50 instead of just P0-P3.

Here are some ideas:

Mirror the obsidian query syntax for inclusive OR queries:

description includes (#P0 #P1)

Use common programming syntax:

description includes #P0 OR #P1
description includes #P0 || #P1
description includes #P0 OR description includes #P1

Logical operators at the start of the filter:

description includes #P0
OR description includes #P1

Logical operators on their own lines:

description includes #P0
OR 
description includes #P1

[schemar]

Thanks for the input @Masstronaut. Keeping ORs on one line could make the parsing and application a little easier, actually 👍

[flatlines]

+1 for this! What a brilliant idea.

[kseinitzer]

I want to achieve the same, but instead of directly using priority tags, I would like to use activity tags and later group my urgent tags together within one view:

# My high prior tasks

```tasks
not done
description includes #importantActivity
description includes #anotherActivity
description includes #alsoImportant
due before next week
```

In my current workaround, I use multiple separate reports:

# My high prior tasks

```tasks
not done
description includes #importantActivity
due before next week
hide task count
```
```tasks
not done
description includes #anotherActivity
due before next week
hide task count
```
```tasks
not done
description includes #alsoImportant
due before next week
hide task count
```

[megclaypool]

I'd very much like the possibility of grouping my queries with both AND and OR... For example, I'd like to be able to pull tasks from multiple documents -- something like:

  not done
  AND
  (
    path includes Task List 
    OR 
    path includes <% templater_code_for_path_to_this_daily_note's_corresponding_weekly_note %>
    OR 
    path includes <% templater_code_for_path_to_this_daily_note's_corresponding_monthly_note %>
  )
  AND
  due on <% templater_code_for_this_note's_date %>

This would allow me to offload my repeating tasks from a single monolithic tasks note to individual templates. I've got to admit, while the repeating tasks are slick and I'm glad to have them, the completed tasks are piling up and filling up my list 😛 I'm not quite sure how to handle it -- it's kind of cool to have a record of what I completed when, but my task list is becoming less and less usable 🤷🏽‍♀️

[marknuzz]

I don't think multiline queries are strictly necessary to implement ORs, and I'd be fine working with single-line queries if that's all that there is time to implement. With that said, if multiline queries are needed, here's a couple of three approaches:

1. Treat parenthesis as a delimiter for treating multi-line statements the same as if they were on a single line. Ignore line breaks within the bounds of the parenthesis. But then you have to deal with the fact that parenthesis syntax implies that boolean expressions can be nested recursively and then there would be somewhat of an obligation to implement that as well, and that would be too much work to justify without a broader strategy. Too much work.

2. Require ORs to exist on single line, and don't support recursion. Would be simple to implement and provide good benefit to a lot of users.

3. To make queries more readable, you can incorporate optional use of semicolons. If any line in the query ends with a semicolon, then the query parser must use the semicolon instead of new line character to specify statement boundaries. Should be doable on a budget timescale as well.

[marknuzz]

I think implementing this would be good to go with the ORs as well and could be done together. #428
Nothing fancy though for that, just use the same pattern as how filters like "not done" were implemented. It wouldn't be a true general-case boolean as one might think at first.

[schemar]

Hey @marknuzz, thank you so much for the offer! ❤️ I also think that supporting ORs only on a single line would already be beneficial to a lot of users.

The queries currently work like this:

1. When the query result is first rendered:
   a. The QueryRenderer gets all tasks from Tasks' cache.
   b. It gets all filters of this ```tasks block (defined by the user in the block) "parsed" from Query.filters.
   c. The query renderer iterates over the list of filters and for each filter it filters the array of tasks (`QueryRenderer` (L150)).
2. When Tasks' cache updates, it triggers an event which is handled by the query renderer to re-render the tasks. The event includes all tasks.

There are three things to note:

1. Always iterating over all tasks is very inefficient, but it is easy to understand and write and so far I didn't get serious complaints about performance.
2. There is quite some code duplication. Would be nice to clean up, but definitely not something I ask of you.
3. This naive implementation can't do OR, as it is nothing more than a list of simple filters that compare a given task's property to something given by the user.

The filters are "parsed" in the constructor of Query.

I think the correct approach to this requirement would be to update Query to parse "smarter". Keep the rest of the process as-is (for now) and focus only there. Ideally, Query would parse the whole ```tasks block into a single filter (instead of an array of filters; could always be an array with the length of 1 for now). If that's not feasible, it's fine to stay with multiple filters.

You would need to incorporate the OR logic into the parsing of the ```tasks block in Query.
And please make sure there are relevant tests.

Hope this helps. If you start working on this, please create a feature issue where you assign yourself. You could also copy this text there.

Let me know if I can help. And thanks again for your offer 🙏

[marknuzz]

Hi @schemar, I will try to get to this when I have free time as I have not had much of it lately. Fortunately something like this could in theory make me more productive and therefore I'm likely to be able to justify the time investment soon (just not this week)

[schemar]

Thank you. Take your time. I’m busy and there are open PRs waiting for me already.

[petegriffith]

This is something I would love to see as well!

[elight]

+1

Alternatively, or in addition: it would be lovely to have a Javascript-based query API perhaps borrowing from DataViewJS with tasksjs.

[elight]

Would love to see interest in this feature lead to a PR. My JS isn't likely up to the task.

[sytone]

There is the for at sytone/obsidian-tasks-x that has more SQL like capabilities that allow complex nesting. It is running ahead of this repo but also taking all updates so it is in parity with the current version. I'm slowly working though getting the changes back in a less impactful way.

[sytone]

Examples

WHERE status->indicator = ' ' AND moment()->format = moment(dueDate)->format
WHERE status->indicator = ' ' AND moment(dueDate)->isBetween(moment()->startOf('day').subtract(1, 'days'), moment()->startOf('day').add(14, 'days'))
WHERE status->indicator = 'x' AND precedingHeader LIKE '%tasks%'
WHERE status->indicator = ' ' AND moment(dueDate)->format = '2021-04-09' AND path LIKE '%GitHub%'
WHERE description LIKE '%waiting%' OR description LIKE '%waits%' OR description LIKE '%wartet%'

[claremacrae]

There has been another request for this at #551.

[claremacrae]

See also another request in #625.

[elight]

@claremacrae One way to get this feature, that would be less accessible to a wide audience, but may simplify the implementation would be to allow the description filter to take a regexp.

Arguably, that would be useful regardless of the presence of "OR" query logic—because why not both?

[elight]

And then I look at this and realize that I should already be able to supply my own regexp in the query!!!!

[elight]

Nope. DescriptionField subclasses TextField which uses a String.include here.

We could add the ability for TextField to also recognize and attempt to match a RegExp when one is supplied. I believe that could be built into the TextField here with some small tweaks.

[claremacrae]

Brilliant idea - and thank you for staring a pull request on it @elight! #790

[sytone]

Had a check and the alasql engine support regex natively as well as via a function so this would be covered.

[esm7]

Hey everybody, I spent some time reading the queries code and I believe I've come up with a syntax that is -

1. Backwards compatible (it's an extension to the existing syntax),
2. As powerful as it gets,
3. Very feasible for me to implement within just a few hours of work.

It looks like this:

not done
(due before tomorrow) AND NOT ((has scheduled date) OR (tag includes later))

(you would be able to use any combination of AND, OR, NOT, XOR and parenthesis)

The idea is to use the existing predicates, but parse logical keywords around them, and additionally, treat a newline as AND (this is the part that ensures backwards compatibility).

If this meets everybody's expectations from this feature, I'd love to start working on it next week. I started using obsidian-tasks this week and still need OR to be able to finish my migration :)

[claremacrae]

That sounds brilliant. Thank you!

[elight]

[esm7]

As promised, here it is: #852

[flatlines]

@esm7 I have just started using the changes and they are amazing. Thank you so much for sharing this with all of us.

[elight]

Very nice!

On August 31, 2022, Vipercat ***@***.***> wrote: @esm7 <https://github.com/esm7> I have just started using the changes and they are amazing. Thank you so much for sharing this with all of us.

— Reply to this email directly, view it on GitHub <https://github.com/obsidian-tasks-group/obsidian- tasks/discussions/121#discussioncomment-3521411>, or unsubscribe <https://github.com/notifications/unsubscribe- auth/AAACPAG4P6F5URTFYGB4TADV366D7ANCNFSM444CK6GA>. You are receiving this because you were mentioned.Message ID: <obsidian- tasks-group/obsidian-tasks/repo- ***@***.***>