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

[ramses0]

# ...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?

[ramses0]

Calling out other discussion on a "2.0" set of issues:

#11 (comment)

• multi-line tasks - discussed in Multi-line tasks #2
• file-level comments - discussed in todo.txt syntax should include a "comment rule" #1 and Versioning todo.txt spec #6
• task-level comments
• markup language support
• multi-project management - mentioned in Version 3.0.0 Spec - My vision of the new version todotxt #13
• open but consequent usage of tags / values

...the issues I've described overlap with [comments] (universally desired), [task-level-comments] (for me that's "data-blob" at the end mostly for URL's).

...and for a snarky versioning name? todo.2do? 2do.txt? ;-)

[dummifiedme]

+1 for that. If there is a way for links and markdown like syntax, it would change the game

[yarcowong]

Hello, check my post: where is the important author tag?

[page200]

IDs wouldn't be a breaking change if we keep the priority such as (A) in the beginning of the line, for example
(A) ID-1234: ____
or
(A) ____ <id 1234>
or whatever (details can be decided later). In other words, this is realizable via your suggestion "open but [consistent] usage of tags / values", which sounds great.

---

Your suggestion for BLOB/URL doesn't look like a breaking change. The existing todo.txt spec seems to allow this. It would look non-nice and might be slow in old todo.txt editors but wouldn't inherently break it. Which is good.

Your suggestion allows only one URL per task. Instead, todo.txt editors like https://github.com/ransome1/sleek (albeit not yet mature) support markdown, so that you can include several URLs per task anywhere in the text rather than at the end, for example:

(A) rename variable `foo` from [here](https://www.foo.com/too-long-url-that-you-dont-want-to-see/) but watch out with [this other link](https://another.url/)

which will render as follows:

(A) rename variable foo from here but watch out with this other link

---

With sections, you want to group several tasks into one section. That's what @contexts and +projects are for, and they are better in that they aren't limited to only one context/project per task. Try todo.txt editors that allow filtering/sorting by contexts and projects.

but often you end up with "cutline" type decisions where something is "above the line" or "below the line" ...

Also with your suggestion, no? Maybe I misunderstand what you mean here.

basically internalizing the inclusion of the idea of "line".

Who internalizes its inclusion where? 🤨

---

A comment should comment on what, the one task that follows it? Then include it in that task.

---

Instead of file-level comments, what about file-level anything (markup, tags, ...). Anyway, that's already supported, namely by creating separate files with any file format you wish.