todo.txt - v2.0 - requested features (comments, data-blob, sections, ids)

# ...comments indicated by leading "#"
(A) - a normal task ::: <DATA-BLOB> after trailing ":::" (or similar)
-----------
(A) - sections / groupings via markdown-ish breaks (3+ dashes)
ISSUE-1234: (A) This is a tracked issue, or referenceable issue-identifier

Comments Benefits: Human-readable instructions, "do-not-process" items, temporarily remove items Drawbacks: Increased complexity, keep comments out of "todo's"

Data-Blob Many of my todo's need a URL, so I've been informally using:

(A) Search for Best Website ::: https://www.google.com/
(B) This is effectively the title ::: this is effectively like a newline or "ignorable" area for most clients
(C) Register for appointment at DMV ::: https://some.long.dmv.url.gov/form/some-thing/here.cfm
(D) A complicated issue ::: { "json": "blob", "goes": "...here..." }

Within my editor, I've tweaked the syntax highlighting to make the URL's and "junk" more ignorable after the "end-of-title" marker (I'm using ::: but I have no special attachment to the syntax).

+ syntax  match  TodoDataBlock  ':::\s.\+$'                 contains=NONE
+ highlight  default  link  TodoDataBlock  Comment

Benefits: consistently allow "fancy" or "ignorable" data (slightly differently from foo:blah-blah which is currently documented) Drawbacks: sometimes really-long-lines, may not want to encourage this type of behaviour of putting a bunch of arbitrary data into a file like this

Sections

Sometimes you have a batch of items which would benefit from grouping. My ideal use case is to be able to sort or filter items only within a section boundary (ie: treat each section as if it were mostly a separate todo.txt document). I'm weakly optimistic about the usefulness of this, it can definitely be simulated via a task with a title of only "------", but often you end up with "cutline" type decisions where something is "above the line" or "below the line" ... basically internalizing the inclusion of the idea of "line".

Benefits: versatile, may match common usage Drawbacks: how is this any different than just an arbitrary task named: "-----"

ID's

"If a task has an identifier it must have a priority. Identifiers must be all-uppercase followed by a dash and a series of numbers and terminated by a colon and space. Regex-ish: ^/[A-Z]+-[0-9]+: .*$/ "

Benefits: allows a bit of round-tripping between common bug-tracking, work-tracking systems (ie: dump-to-todo.txt), ability to refer to presumably unique identifiers Drawbacks: increased complexity, may not support tracking systems with non-numeric identifiers

# this is an example "v2.0" proposal for todo.txt
ISSUE-001: (A) `todo.txt` does not support comments or identifiers
(B) review `todo.txt` issues ::: https://github.com/todotxt/todo.txt/issues
-----------
# issues below here are unlikely to be tackled this week
(C) fix all the bugs
(D) make tons of improvements

To be clear: My request / proposal is mostly to determine what "breaking" changes for todo.txt tools would be valuable. I've discovered: [ ids, data-blobs, comments, sections/breaks ]. I'm proposing the above topics with a proposed syntax/rules.

ID's: ID-1234: (A) ____ Data: ____ ::: https://url.goes.here.com/ Comments: # ______ Sections: --------

...I would suggest any "v2" discussions split between capabilities and syntax-for-those

I'd love feedback on thumbs-up/thumbs-down specifically for the CAPABILITIES suggested here, and a lot less feedback/bike-shedding on this particular syntax. eg: if "comments" are universally accepted, then syntax may be: #, //, --, /* ... */, etc..., but do people agree that "comments" are something that has a place in the format? Same with data-blobs ( ::: .*$ or { ... }$ or >>> .*$, etc.)... is it a useful concept or should it be omitted?

todotxt / todo.txt

todo.txt - v2.0 - requested features (comments, data-blob, sections, ids) #30