ransome1 / sleek

todo.txt manager for Linux, Windows and MacOS, free and open-source (FOSS)
https://github.com/ransome1/sleek/wiki
MIT License
1.28k stars 99 forks source link

In the wiki's Filter Expressions "Quick Start" guide, `due` needs a trailing colon #642

Closed DeflateAwning closed 5 months ago

DeflateAwning commented 5 months ago

Bug Report

Important

App Version: v2.0.8

Platform: Linux

Installation Method: deb

Bug Description: Most of the examples in the wiki's Filter Expressions "Quick Start" guide don't work. It appears that they work if you add a trailing colon after due, though.

For example, this is what's in the guide, but doesn't seem to work: +bills and due < tomorrow. Here's how I'm pretty sure it needs to be currently +bills and due: < tomorrow

Solution (easy, preferable): update that guide to include the colon suffix.

Solution (hard, maybe better? probably not though): make it so that due date filters work without a colon after due.

Guide in question: https://github.com/ransome1/sleek/wiki/Filter-Expressions-for-Advanced-Search

zerodat commented 5 months ago

Good catch, @DeflateAwning . The original syntax of the filter expression language used due and t as keywords, and so it was documented that way. Then I modified the syntax in PR #435 to require the colon after the keyword, because people were having trouble matching freeform text that started with t (issue #311). Unfortunately, we didn't update the filter expressions doc. The right thing to do now is to update the doc.

zerodat commented 5 months ago

@DeflateAwning I just made a pass to update the wiki page with the correct new syntax. Please let us know if you still see any broken examples in there. Thanks for spotting this issue! Please close this if you agree that the wiki page is now fixed.

ransome1 commented 5 months ago

@zerodat I scanned the wiki page quickly. As of now most of the attributes can be used in a consistent way such as due: > today or rec: == d.

However for the priority we're going a different route, if I'm not mistaken. Instead of pri: == A, which would be consistent I'd say, users have to type pri == A without the colon.

I cannot recall all our past discussions but was this a deliberate choice?

andrei-a-papou commented 5 months ago

Regex matching doesn't seem to work for me, example: /.*window.*/. This matches nothing, but I have four todos with the word window in them. If I just type window into the search field, I catch them all.

andrei-a-papou commented 5 months ago

Another example: window +sleek matches nothing, but I have three todos with the word window in them that have project +sleek assigned to them. window and +sleek doesn't show anything either.

andrei-a-papou commented 5 months ago

And here's a third: due: <= tomorrow+1d doesn't match todos that are both overdue and are due by the day after tomorrow. due: <= tomorrow works as expected.

DeflateAwning commented 5 months ago

Thanks for updating the wiki! This resolves my issue (as presented here), so I'm going to close this issue.

I'll propose that @andrei-a-papou opens a new issue if there are any related remaining issues with functionality (as opposed to documentation).

zerodat commented 5 months ago

@ransome1 I noticed that pri(ority) doesn't have a colon as well. This was the original syntax, and it didn't get changed when I changed t: and due:. I think the justification is that pri: is not a tag in todo.txt, but rather part of the built-in syntax (A) etc. So it seemed odd to put a colon after it like we did with the tag keywords. You can match priorities just using (A) and so on, but if you need to check for inequality, like pri < D you would need the pri (or priority) keyword. Personally, I don't care which way we do it, but that is the argument for leaving it as is.

zerodat commented 5 months ago

@andrei-a-papou I've tried some of the tests that you described and it does seem to be broken in 2.0. I think this worked properly in the later 1.x versions. I'll take a look when I get time and try to figure out why it is broken. It would be helpful if you could file a new issue about it, as @DeflateAwning suggested. Thanks.

andrei-a-papou commented 5 months ago

@zerodat Done: https://github.com/ransome1/sleek/issues/647