Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Can key-value pairs appear anywhere in the line? #69

Open
xsrvmy opened this issue Jan 17, 2022 · 2 comments
Open

Can key-value pairs appear anywhere in the line? #69

xsrvmy opened this issue Jan 17, 2022 · 2 comments

Comments

@xsrvmy
Copy link

xsrvmy commented Jan 17, 2022

It's not clear from the spec whether a key-value pair can appear in the middle of the task name like projects and contexts.
For example: what happens with the following line:

(A) After 11:00am, go to the bank

Another question that comes up in this case is whether or not keys should be restricted not start with a number

@rachmadaniHaryono
Copy link

todo.txt user here

my impression is that key-value tag will be handled by your program

there is no requirement on description section that tag (project, context, and 'special key/value') should appear in the same order like in the example

example on 1 put project tag in the middle of description section

but i agree this should be stated for more clarification

maybe add to rule 3 or new rule (rule 4)

Another question that comes up in this case is whether or not keys should be restricted not start with a number

i don't recommend it

key-value tag already have limitation 2 so it should be good enough for now, unless there is problem

Footnotes

  1. https://github.com/todotxt/todo.txt#rule-2-a-tasks-creation-date-may-optionally-appear-directly-after-priority-and-a-space

  2. https://github.com/todotxt/todo.txt#additional-file-format-definitions

@clach04
Copy link

clach04 commented Sep 11, 2022

The current SVG https://github.com/todotxt/todo.txt/blob/8d19d67227f0a695303c29159bd7bb5c77a21fdb/description.svg makes clear that key/values can be anywhere in or after the description, but adding to the end is a good convention. I suspect this wasn't present when this issue was opened.

Good catch on the time example. I opened a new ticket #77.

@xsrvmy I recommend closing this issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants