Closed callegar closed 1 year ago
I definitely don't want creation dates imposed on me.
Can you not add a creation date if you want that: https://github.com/ransome1/sleek/wiki/Hidden-preferences,-custom-variables-and-command-line-parameters#append-start-date-on-todo-creation
If there is a specification for the todo.txt
format, then IMHO sleek should have a default behavior consistent with it. I understand that using a dialect of the todo.txt
specification may be convenient, but probably should not be the default. I also understand that the specification itself is rather ambiguous (as illustrated in https://github.com/todotxt/todo.txt/issues/70) and that de facto standards exist possibly deviating from the specs, but ignoring the spec will not help it become more robust and correct.
Furthermore, the wiki seems wrong in saying that "per default sleek will append a start date". The opposite appears to be true. And setting appendStartDate
to true
does not seem to have any effect.
Yes but the spec is not that there has to be a creation date. It is up to the user to have created a creation date if they want a later want a completion date. So not making a creation date is consistent with the spec.
In this case, sleek
should not write a completion date, but currently it does unconditionally. If there is no creation date and no completion date, the possibility of setting recurrence should also be disabled, I think.
Fair enough. The spec does seem odd though - I cannot see why a completion date should not be permitted if there is no creation date -- that seems completely arbitrary and unnecessary.
that seems completely arbitrary and unnecessary
I think that it is because otherwise having a single date it would be impossible to know if it is a creation date or a completion date.
The spec does seem odd though
Main problem is that the "visual" spec (the image) is at times in contradiction wit the "textual" spec.
I agree, the image contradicts the text. I believe the text file is clear on the rules for dates and should be used as primary source, see https://github.com/todotxt/todo.txt#rule-2-the-date-of-completion-appears-directly-after-the-x-separated-by-a-space
You are probably right, but English text is not the best tool to specify a formal grammar and is always going to be ambiguous and subject to some interpretation (e.g. would a tool only using the key:value format and never the parenthesis based notation to express priority be within the golden standard? If in a non completed task I specify a priority with (...)
and then again with pri:..
is it OK? And if they do not agree?).
The very conclusion "completion dates are required, creation dates are optional" appears a quite reasonable extrapolation from the text, but the text never says so explicitly :-(
I fear that with this loose specification there are always going to multiple not fully interoperable dialects of todo.txt
. Maybe, at least formalizing one and giving a name to it could be a good thing (just like people caring about correct interoperability refer to "GitHub Markdown " or "CommonMark Markdown" or "Pandoc Markdown", because Markdown... https://babelmark.github.io/faq/#what-is-this-for)
Personally, I would like to have the creation dates for tasks, because it is always easy to transform a text file removing some information, but augmenting it later to add some missing piece is impossible. It is also a pain I have to write these dates manually at every task creation, so I wish bug 474 and 401 could get fixed. It is always a matter of personal usage practice what is best, so I am totally happy about having this under an option (after it is fixed, promoting it to not being hidden would help, though).
Incidentally, I also find it rather inelegant that you need to use two different ways to specify priority depending on whether the task is completed or not. Personally I would not dislike a dialect following the original image based specification allowing x (A) 2023-05-01 ...
enabled under an option.
Incidentally it seems weird that the rationale about almost every aspect of the specification seems to be natural sorting, given that this is a computer related standard, so the only important thing would be to make it easy to isolate the individual fields of the record, so that you can sort based on any field in any order with plain text manipulation tools.
I think that it is because otherwise having a single date it would be impossible to know if it is a creation date or a completion date.
Not really. First date after x is completion date since completion dates are required
Is it an actual bug?
I believe that
sleek
intends to be compatible with thetodo.txt
syntax. If so, this is a bug.Did you check if the bug has already been reported?
Checked
Describe the bug
The
todo.txt
specification found on https://github.com/todotxt/todo.txt says that creation date must be specified if completion date is. See the following illustration:To Reproduce Steps to reproduce the behavior:
Do you see any error entries in sleeks developer tools?
N/A
Expected behavior
When creating a task, sleek should add a creation date, so that when the task is marked as completed the creation date is there together with the completion date.
Screenshots
N/A
Desktop (please complete the following information):