Developing on discussion from #97 and #99 (which should be marked redundant, replaced with this issue?).
I'm not sure of my reasoning for the selection of letters was back there, but these seem right to me now:
tag[c]:2 for count
tag[c]:7/10 for count with target
tag[t]:33m for timer
tag[r]:weekly for repeatable
That's...
c for count
t for timer
r for repeatable
Though keep in mind that repeatable is a special value, intended to lead to duplication and therefore the tag itself probably shouldn't be repeatable per item...
It might be better in that case to just assume a tag of repeats: is to be reserved and should indicate repetition when the item is closed.
A user may wish to have multiple counts or multiple timers on a todo however, so these must be nameable separately and therefore denoted by the flag idea we're working out here.
Perhaps any/all of these should be valid:
repeats:weekly
schedule[r]:weekly
[r]:weekly
That last example is special. The tag has no name, but still defines the repetition rules. It raises the question of reserving single-character tags for these purposes too:
c:2
c:7/10
t:1h43m
r:weekly
s:weekly
The solution that most stands out to me right now is this: name[a-z]:value denoting count and timer tags (name is optional) and three reserved words for use as a single count, single timer and repetition/scheduling:
These features will ultimately be added one at a time and their features and final decisions about their handling can be addressed at that time. Order of implementation is probably determined by ease which is likely...
count
timer
repeats
I do want to note here though that timer should have knowledge of an estimate if one is present... This could be handled similar to count:
myTimer[t]:55m/2h30m
...but this isn't necessarily super clear. Not like, say, estimate:2h30m is clear!
If only onetimer: and oneestimate: is present, solution is simple... assume they are linked. But if there are multiple timers? It's difficult to know which one to associate with the estimate. This should therefore probably be detailed in the spec.
The likelihood of anybody wanting multiple timers on a single item is... probably not very. But for that, there is the myTimer[t]:55m/2h30m approach, besides which reserved names (timer: and estimate:) are provided to offer greater clarity to non-power users.
Sounds good to me.
Code of Conduct
[X] I agree to follow this project's Code of Conduct
Feature request
Developing on discussion from #97 and #99 (which should be marked redundant, replaced with this issue?).
I'm not sure of my reasoning for the selection of letters was back there, but these seem right to me now:
That's...
cfor counttfor timerrfor repeatableThough keep in mind that repeatable is a special value, intended to lead to duplication and therefore the tag itself probably shouldn't be repeatable per item...
It might be better in that case to just assume a tag of
repeats:is to be reserved and should indicate repetition when the item is closed.A user may wish to have multiple counts or multiple timers on a todo however, so these must be nameable separately and therefore denoted by the flag idea we're working out here.
Perhaps any/all of these should be valid:
That last example is special. The tag has no name, but still defines the repetition rules. It raises the question of reserving single-character tags for these purposes too:
The solution that most stands out to me right now is this:
name[a-z]:valuedenoting count and timer tags (name is optional) and three reserved words for use as a single count, single timer and repetition/scheduling:Reserved words: count, timer, repeats and... maybe also: due, schedule, est/estimate
These features will ultimately be added one at a time and their features and final decisions about their handling can be addressed at that time. Order of implementation is probably determined by ease which is likely...
I do want to note here though that timer should have knowledge of an estimate if one is present... This could be handled similar to count:
...but this isn't necessarily super clear. Not like, say,
estimate:2h30mis clear!If only one
timer:and oneestimate:is present, solution is simple... assume they are linked. But if there are multiple timers? It's difficult to know which one to associate with the estimate. This should therefore probably be detailed in the spec.The likelihood of anybody wanting multiple timers on a single item is... probably not very. But for that, there is the
myTimer[t]:55m/2h30mapproach, besides which reserved names (timer:andestimate:) are provided to offer greater clarity to non-power users.Sounds good to me.
Code of Conduct