todotxt / todo.txt

‼️ A complete primer on the whys and hows of todo.txt.
GNU General Public License v3.0
2.33k stars 102 forks source link

List of "Special tag / Additional Definitions" #8

Open heX16 opened 6 years ago

heX16 commented 6 years ago

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

due:2017-01-01 hide:1

Where can I find the full list? (And add to it)

karbassi commented 6 years ago

@heX16 there is no full list since each person can use their own set of special tags.

The ones I've seen used across tools have been

Maybe it's time we set a few that are part of the standards, such as due and t.

Thoughts @todotxt/core

ginatrapani commented 6 years ago

What's threshold date?

Anecdotally, and historically, due date has by far been the most-requested addition to the standard. I've pushed back on it for lots of reasons (I'm sure there are ancient discussion threads about this on the mailing list), but I'm fine with revisiting.

karbassi commented 6 years ago

What's threshold date?

The t tag gives a start date to an item (also called a threshold, hence the t). It's another way of filtering.

Example

(B) Call mom about dad's birthday gift due:2017-05-06 t:2017-04-20

While the task is due on May 5, 2017, I don't want to see it on my list (via a tool) until April 20, 2017. Moreover, some tools allow customizing how far ahead you want to see a task. Such as, show me tasks that have thresholds X days in the future.

ginatrapani commented 6 years ago

Ah okay, thanks for explaining.

My general view has been: as soon as more dates get involved things get pretty complex pretty fast. To me, todo.txt is a task list, not a reminder tool, or a calendar, so these two dates feel outside of the scope of the spirit of the app. Not to mention what a significant burden it would put on client developers to accommodate a not-small amount of date math and other complexity (like hiding tasks that aren't complete but haven't hit their threshold date yet -- that would confuse me if I opened the file in a text editor, and the point of the format is to offer a human-readable text file that can easily be manipulated in any editor).

Anyway, as always, open to dissenting opinions, but if we go back to guiding principles, I think something like threshold date is too much. There's probably a case to be made for due date, though.

bram85 commented 6 years ago

I don't think we should enforce certain tags in the standard, but rather as a recommendation / common practice. Some tools share the same semantics, but that's about it.

Perhaps we could maintain a table of known todo.txt tools (perhaps a public Google sheet) with the tags that they use (syntax, semantics, and whether the tag name for that semantic is configurable).

ginatrapani commented 6 years ago

I don't think we should enforce certain tags in the standard, but rather as a recommendation / common practice.

Oh, I think this is a good idea. Documenting the additional tags various clients have landed on as guidance for the community would be great.

karbassi commented 6 years ago

I second this. If you look at the original task, @heX16 just wants a list of what's possible.

Moreover, it would really help get the tool developers in sync.

bram85 commented 6 years ago

I made a brief start at https://docs.google.com/spreadsheets/d/11nqV2j8qc_O5SVsvkZ2JGZP98CABLQ6EwBxAQQi7Huc/edit?usp=drivesdk

Feel free to extend it with other clients. Also, I'm not sure how to deal with the add-ons for the original CLI. Perhaps a comment referring to the add-on would do.

evanp commented 6 years ago

This is a great idea. I added the issue prefix to @bram85 's spreadsheet. Maybe get this moved to Github, though?

thebluesnevrdie commented 6 years ago

One that seems to be the most obvious missing to me is a dependency tag. I would think dependency and due date tags should even be considered officially supported per the format definition as those are pretty much universally supported in just about every task management tool ever built...

tomByrer commented 6 years ago

So seems the most used tages are threshold, recurring, & hide.

most obvious missing to me is a dependency tag

I was thinking of using 'less than' & 'greater than' symbols: > depending on / waiting for

farvardin commented 3 years ago

I'm quite surprise there is no "complete" (or completeness) status of a task in percent or in number of items to complete. It could be comp:17% and comp:5/7

It would be useful to quickly see if a task is near completion or not (like writing a book, painting a wall...)

If it was an official recommendation, some tools could implement it with a status bar for example.

Here is a basic exemple with a html rendering which parses a todo file: image

codingthat commented 3 years ago

@farvardin Just to throw an alternative approach out there: All chapters for a book is a rather big task, so maybe it could be a subproject instead, consisting of tasks like "Write chapter 1" etc. (and further broken down, if you so desire). Then it should be relatively straightforward to ask the software what percentage of chapters are done, instead of you having to calculate it manually. In fact, I think that's exactly what the birdseye extension does for you...

clach04 commented 1 year ago

Android SimpleTask, from https://github.com/mpcjanssen/simpletask-android/blob/master/app/src/main/assets/index.en.md#extensions (as of 2022-09-11):

Simpletask supports the following todo.txt extensions:

Simple task also has option uuid

clach04 commented 1 year ago

Seen ttps://gitter.im/todotxt/Lobby?at=6284470aeaf3267f8566d9e3:

id: blocks:1

I've also seen p:1 to show the parent (for sub-tasks).

clach04 commented 1 year ago

Just realized spec has another one listed https://github.com/todotxt/todo.txt#rule-2-the-date-of-completion-appears-directly-after-the-x-separated-by-a-space as part of priority for completed tasks:

pri:A
clach04 commented 1 year ago

wait:

https://lwn.net/Articles/824608/

Hide until wait date, essentially an expected start date