Completion date: after x or after priority?

[vise890]

In the main section there is this picture:

.. which seems to suggest that the completion date goes after the (optional) priority, so a completed todo with both creation and completion dates would look like:

x (A) 2020-12-27 2020-12-27 Call nicoletta @phone t:2020-12-27 

However, later on, in the final remarks on completion dates it says that:

The date of completion appears directly after the x, separated by a space

And this example is given:

x 2011-03-02 2011-03-01 Review Tim's pull request +TodoTxtTouch @github

Should the image in the main section be clarified? Am I missing something?

Cheers

[bobwhitelock]

I agree this is slightly confusing - my interpretation has always been as in the image, that any priority for a completed task will always be the second part of the task, between x and the completion date. I think the second part you quote could definitely be improved to mention this situation, but doesn't necessarily contradict the image at the moment, since the example task shown doesn't have a priority (so it could just be describing a simple case).

I think one thing that means this doesn't come up much in practise is that it seems like most programs that interact with todotxt files clear out the priority on task completion - e.g. using 2 such programs I have on my computer at the moment, the todotxt CLI (the closest thing there is to a reference implementation) will just remove the priority when you complete a task, while the todotxt Vim plugin will remove it and re-add it as a tag on the end (e.g. (A) gets added as pri:A). My guess as to the reasoning for this is that a priority isn't very useful for an already completed task, and removing these gives the more useful behaviour of having a list of completed tasks automatically be sorted by their completion date.

[bobwhitelock]

I agree this is slightly confusing - my interpretation has always been as in the image, that any priority for a completed task will always be the second part of the task, between x and the completion date. I think the second part you quote could definitely be improved to mention this situation, but doesn't necessarily contradict the image at the moment, since the example task shown doesn't have a priority (so it could just be describing a simple case).

I think one thing that means this doesn't come up much in practise is that it seems like most programs that interact with todotxt files clear out the priority on task completion - e.g. using 2 such programs I have on my computer at the moment, the todotxt CLI (the closest thing there is to a reference implementation) will just remove the priority when you complete a task, while the todotxt Vim plugin will remove it and re-add it as a tag on the end (e.g. (A) gets added as pri:A). My guess as to the reasoning for this is that a priority isn't very useful for an already completed task, and removing these gives the more useful behaviour of having a list of completed tasks automatically be sorted by their completion date.

[vise890]

(Sorry for the late reply)

Ok that makes sense, as a third case Simpletask leaves the priority between completion and creation date:

x 2020-12-31 (A) 2020-12-12 foo bar baz

I guess it doesn't matter too much as it is relatively easy to determine which one is the completion, which one is the creation and which was the priority (whether it appears after the x, after the completion or after both.. I am building my parser to cater to all those cases.. ¯\(ツ)/¯

Still, it'd be good to have a canonical representation for it..

[vise890]

(Sorry for the late reply)

Ok that makes sense, as a third case Simpletask leaves the priority between completion and creation date:

x 2020-12-31 (A) 2020-12-12 foo bar baz

I guess it doesn't matter too much as it is relatively easy to determine which one is the completion, which one is the creation and which was the priority (whether it appears after the x, after the completion or after both.. I am building my parser to cater to all those cases.. ¯\(ツ)/¯

Still, it'd be good to have a canonical representation for it..

[bobwhitelock]

Ah that's interesting re simpletask, I guess that's a counterexample to my experience and intuition. I also wrote a todotxt parser recently and should make sure it handles that situation as well!

[bobwhitelock]

Ah that's interesting re simpletask, I guess that's a counterexample to my experience and intuition. I also wrote a todotxt parser recently and should make sure it handles that situation as well!