For those familiar with the todo.txt format Toodles is based on, it would be a lot more comfortable to simply be able to write the todo directly into the text input bar:
(A) 2024-09-01 My todo for September 1st
This is similar to something I've just written into the input bar before catching myself. It's actually wrong anyway - todo.txt wouldn't treat a single date as a due date and neither does Toodles (first date would be created date) - but it's what I tried to enter:
priority + due date + description
It makes a lot of sense to support this format, along with price and multiplier.
We omit created date handling because... you're creating it right now - we know that!
You might choose to provide two dates, in which case we might treat the first as the created and the second as due.
You might want to add a done todo:
x This todo is done!
In this case, if you did provide a date we would treat it as the completion date. If you provided two dates, we would treat them as the completed and then created dates. If you provide three, then that third date is the due date.
My reasoning?
For open todos, we know when you're creating it (now) so due is the most relevant date you could provide
For closed todos, due isn't as necessary (you've done it already!) so completed date makes the most sense (we'll set the completed and the created to the date you provide)
If you do supply additional dates, then for open todos it is clear these are your created and due dates, and for closed todos it's just exactly to spec: x completed created due description <- that's the spec
So it's about what information are you most likely to want to input. For open todos, that's due. For closed, it's the completed date.
Everything else should behave as standard. And these new behaviours should be ignored if the values provided in the string are overridden by the advanced form features... right?
If due is provided in the advanced form, any date at the beginning of the description input can be treated as a created date. But say... if a price were provided in advanced input, we'd ignore the one in the description input and treat it as just part of the description. Same for multiplier.
This makes the most sense to me right now, but is all open to revision.
Code of Conduct
[X] I agree to follow this project's Code of Conduct
Feature request
For those familiar with the todo.txt format Toodles is based on, it would be a lot more comfortable to simply be able to write the todo directly into the text input bar:
This is similar to something I've just written into the input bar before catching myself. It's actually wrong anyway - todo.txt wouldn't treat a single date as a due date and neither does Toodles (first date would be created date) - but it's what I tried to enter:
It makes a lot of sense to support this format, along with price and multiplier.
We omit created date handling because... you're creating it right now - we know that!
You might choose to provide two dates, in which case we might treat the first as the created and the second as due.
You might want to add a done todo:
In this case, if you did provide a date we would treat it as the completion date. If you provided two dates, we would treat them as the completed and then created dates. If you provide three, then that third date is the due date.
My reasoning?
x completed created due description<- that's the specSo it's about what information are you most likely to want to input. For open todos, that's due. For closed, it's the completed date.
Everything else should behave as standard. And these new behaviours should be ignored if the values provided in the string are overridden by the advanced form features... right?
If
dueis provided in the advanced form, any date at the beginning of the description input can be treated as a created date. But say... if a price were provided in advanced input, we'd ignore the one in the description input and treat it as just part of the description. Same for multiplier.This makes the most sense to me right now, but is all open to revision.
Code of Conduct