Support parsing start dates and due dates for "next month", "next year" and "next quarter" in Quick Add entry syntax

[Karnaphorion]

On the 0.6 github release.

Quick entery "my task due:tomorrow" creates a new task "my task" and fill the due date field with tomorrow, as expected.

Quick entry "my task due:next month" creates a new task "my task due:next month" and doesn't fill the due date field, not as expected.

Tried without success :

my task due:next month my task due:"next month" my task due:'next month' my task due:(next month) my task "due:next month" my task due:next year

The space in the date seems to be the issue.

@Neui found the line responisble for this behavior

Looking in the code it appears it only expects one word (on both sides of the :), so next month and such won't work.

[nekohayo]

Do you mean the 0.6 stable release, or the current git master version?

[Karnaphorion]

@nekohayo The 0.6 stable release. I've downloaded the gtg-0.6.0.tar.xz archive file, that's what I am currently running.

[nekohayo]

I'm not sure we've ever supported such fuzzy dates in the syntax for new task creation (vs deferring existing tasks). Indeed I don't see how this could work with spaces only, it would need _ or no space or ( ) " as you would have expected, but I guess it's not implemented. And the related documentation page would then need to be updated and complexified.

On a tangential note: if supporting months and years, we might as well support quarters too, while we're at it.

---

The current workaround you have is to use the Task Editor GUI, which does support this (to my surprise):

[Karnaphorion]

If I understand the code correctly,

Writing something in the due date field triggers GTG.core.dates.Date.parse() here which triggers _parse_text_representation() which parse correctly "next week" as a date.

And the only thing not allowing that in Quick Add is the token regex here

Maybe allowing a single space between 2 words in the regex formula could do the trick ?

Okay, that's maybe more tricky that I imagined but that expression seems to work : ([\s]*)([\w-]+):\s*(([^\s]+)(?=( [\w]+:))|([\w]+ [\w]+)|([^\s]+))

Regex doesn't usually support overlapping, but using priorities and positive lookhead makes for a workaround.