Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

project.not:side-quest or urgency>5 no longer working in 3.0.2 for context definition #3440

Open
adriangalilea opened this issue May 5, 2024 · 14 comments

Comments

@adriangalilea
Copy link

I had:
context.default.read=project.not:side-quest or urgency>5

For my default context, and after upgrading to 3.0.2 (haven't tested 3.0.0/1) it no longer works, how can I use the urgency filter again?

I also tried:
context.default.read="project.not:side-quest or urgency>5"

And it did not work either

More testing:

task list "project.not:side-quest or urgency>5"
Does not work

but
task list "urgency>5"
and
task list "project.not:side-quest"

Work well when used in isolation.

Funniest thing is
priority:H or +next or urgency>5

This works perfectly fine, so I have no clue what's causing it not to work, is it project.not or a project with a - ?

@adriangalilea adriangalilea changed the title urgency>5 no longer working in 3.0.2 for context definition project.not:side-quest or urgency>5 no longer working in 3.0.2 for context definition May 5, 2024
@djmitche
Copy link
Collaborator

djmitche commented May 6, 2024

ISTR projects can't have a - in them, as the command-line parser interprets that as subtraction. But #1537 suggests that was fixed 6 years ago.

Also, I can't reproduce this:

⸩ task list "project.not:side-quest or urgency>4"
Found existing '*.data' files in /home/dustin/.task
  Taskwarrior's storage format changed in 3.0, requiring a manual migration.
  See https://github.com/GothenburgBitFactory/taskwarrior/releases.

ID Age  P Project    Tags Description Urg 
 3 3min M            next bing        18.9
 2 4min M main-quest      bar          4.9
 1 4min M side-quest      foo          4.9

3 tasks

What does "no longer works" mean?

@adriangalilea
Copy link
Author

adriangalilea commented May 6, 2024

It doesn't work to me, it literally gives me a list of all the tasks, including below 4 urgency side-quest's

image

it was working fine in 2.6 tho.

@djmitche
Copy link
Collaborator

djmitche commented May 6, 2024

Hm, it looks like all of those tasks match project.not:side-quest The few at the bottom have a similar project, but it doesn't match exactly. Which of those would you expect to not see?

@adriangalilea
Copy link
Author

adriangalilea commented May 6, 2024

Hm, it looks like all of those tasks match project.not:side-quest The few at the bottom have a similar project, but it doesn't match exactly. Which of those would you expect to not see?

The tasks at the bottom are from project side-quest so they should be excluded regardless of how you interpret the filter, no? I would understand if they showed up if they had urgency above 5 but is not the case.

I think my intention was something like "show me all tasks with urgency above 5 unless it's from project side-quest" I would be fine if it interpreted it as "show me all tasks that are not from project side-quest unless they have urgency above 5" but neither seems to happen.

I'm positive it was working as expected in 2.6, do you want me to test it? I have a backup of my exported tasks, I can install it in a venv or something.

@djmitche
Copy link
Collaborator

djmitche commented May 6, 2024

I think project.not is doing an exact match, and not with regard to subprojects. So side-quest.e-id is "not" side-quest. I could be wrong, though - I have not looked at the filtering or project code.

I don't think anything related to this changed in the 3.0 release. If you export from 3.0 and re-import the same in 2.6 (maybe just installed in a temporary VM or container), is the output different?

@djmitche
Copy link
Collaborator

djmitche commented May 7, 2024

Huh, I am wrong:

✖ sofia ~/p/taskwarrior ⸨issue3429⸩
⸩ t
ID Age   Project Description Urg 
 1 23h   foo     foo            1
 2 23h   foo.bar foo            1

2 tasks
✖ sofia ~/p/taskwarrior ⸨issue3429⸩
⸩ t list project.not:foo
No matches.
✖ sofia ~/p/taskwarrior ⸨issue3429⸩
⸩ t list project.not:foo.bar

ID Age   Project Description Urg 
 1 23h   foo     foo            1

1 task

It looks like it's doing a prefix match, which is to say, project.not:foo says "project does not begin with foo"

That said, I can replicate what you are seeing even with 2.6.2:

✖ sofia ~                                                                                                                                                                                                                                                                                                                      
⸩ t 'project.not:side-quest or urgency>5'                                                                                                                                                                                                                                                                                      
...
88 side-quest M               21h    4.9 magnets

Task 88 has an urgency of 3.9. It does not appear in task project.not:side-quest nor task "urgency>5".

To be honest, I have no idea how the filtering works in Taskwarrior, so I'm not sure how much more help I can be.

@adriangalilea
Copy link
Author

Ok, this is very odd,

I created this issue because my context wasn't working and when I tried using task list with the filter I replicated it not working.

Then I recreated my 2.6 and it worked just fine, but then I returned back to my machine and it's also working.

image

As you can see no side-quest task in sight, however if I run, task list "project.not:side-quest or urgency>5" it doesn't filter and gives me the whole task list, so perhaps for whatever reason my context didn't work momentarily and when I tried to debug with task list or task it didn't work so I assumed it was a bug and didn't try further.

@djmitche Try the very same filter but in an actual context and tell me if it works for you as it works for me,

I'm not sure what's going on, wasn't the filter of the context supposed to work the same as when used on task or task list?

I gotta say, I'm quite a bit dyslexic and some of it may be my brain malfunctioning. So apologies for that and thank you so much for your help.

@djmitche
Copy link
Collaborator

djmitche commented May 9, 2024

I don't know much about context, to be honest. Maybe there's something in how the filter supplied by the context is combined with the filter on the command line?

@adriangalilea
Copy link
Author

I don't know much about context, to be honest. Maybe there's something in how the filter supplied by the context is combined with the filter on the command line?

No idea, but I thought context definition and task list "..." was supposed to work the same.

@djmitche
Copy link
Collaborator

Me too :)

@adriangalilea
Copy link
Author

Some funny results:

This doesn't do anything:

❯ task "project.not:side-quest or urgency>5" list

This work perfectly:

❯ task project.not:side-quest or urgency\>5 list
❯ task list project.not:side-quest or urgency\>5

Fails:

❯ task list \(project.not:side-quest or tags.not:side-quest\) or urgency\>5
Mismatched parentheses in expression

Works:

task list "(project.not:side-quest and tags.not:side-quest)" or urgency\>5

Overall very inconsistent and hard to pick up, I think this needs better documentation and perhaps a re-work.

What do you think @djmitche

I managed to make default context as I intended:
context.default.read=(project.not:side-quest and tags.not:side-quest) or urgency>5

Now I'll not see side-quest's either from projects under side-quest or specifically tagged side-quest tasks, unless they are urgent :)

@djmitche
Copy link
Collaborator

I'm glad you got this sorted out for yourself!

That certainly looks like a parsing issue. I had always assumed that Taskwarrior kind of puts all of the command-line "words" back together separated by spaces, and then re-parses them. So, in

❯ task "project.not:side-quest or urgency>5" list

it parses project.not:side-quest or urgency>5 as a filter, and I would expect in

❯ task project.not:side-quest or urgency\>5 list

it gets the "words" project.not:side-quest, or, and urgency>5 from the shell, joins them with spaces, and parses the exact same thing. But, it seems that's not the case.

I don't know if there's anyone around who understands the command-line parsing well enough to explain the difference..

@adriangalilea
Copy link
Author

I don't know if there's anyone around who understands the command-line parsing well enough to explain the difference..

This worries me a bit, does it mean no one is supporting that part of the code anymore?

@ryneeverett
Copy link
Contributor

This seems like another zshell issue. Were any of the incorrect results reproducible on bash? I doubt there ever was full zshell support.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants