Giter VIP home page Giter VIP logo

todo.txt's Introduction

todo.txt format

Gitter

A complete primer on the whys and hows of todo.txt.

The first and most important rule of todo.txt:

A single line in your todo.txt text file represents a single task.

Why plain text?

Plain text is software and operating system agnostic. It's searchable, portable, lightweight, and easily manipulated. It's unstructured. It works when someone else's web server is down or your Outlook .PST file is corrupt. There's no exporting and importing, no databases or tags or flags or stars or prioritizing or insert company name here-induced rules on what you can and can't do with it.

The 3 axes of an effective todo list

Using special notation in todo.txt, you can create a list that's sliceable by 3 key axes.

Priority

Your todo list should be able to tell you what's the next most important thing for you to get done - either by project or by context or overall. You can optionally assign tasks a priority that'll bubble them up to the top of the list.

Project

The only way to move a big project forward is to tackle a small subtask associated with it. Your todo.txt should be able to list out all the tasks specific to a project.

In order to move along a project like "Cleaning out the garage," my task list should give me the next logical action to take in order to move that project along. "Clean out the garage" isn't a good todo item; but "Call Goodwill to schedule pickup" in the "Clean out garage" project is.

Context

Getting Things Done author David Allen suggests splitting up your task lists by context - ie, the place and situation where you'll work on the job. Messages that you need to send go in the @email context; calls to be made @phone, household projects @home.

That way, when you've got a few minutes in the car with your cell phone, you can easily check your @phone tasks and make a call or two while you have the opportunity.

This is all possible inside todo.txt.

todo.txt format rules

Your todo.txt is a plain text file. To take advantage of structured task metadata like priority, projects, context, creation, and completion date, there are a few simple but flexible file format rules.

Philosophically, the todo.txt file format has two goals:

  • The file contents should be human-readable without requiring any tools other than a plain text viewer or editor.
  • A user can manipulate the file contents in a plain text editor in sensible, expected ways. For example, a text editor that can sort lines alphabetically should be able to sort your task list in a meaningful way.

These two goals are why, for example, lines start with priority and/or dates, so that they are easily sorted by priority or time, and completed items are marked with an x, which both sorts at the bottom of an alphabetical list and looks like a filled-in checkbox.

Here are the rest.

Incomplete Tasks: 3 Format Rules

The beauty of todo.txt is that it's completely unstructured; the fields you can attach to each task are only limited by your imagination. To get started, use special notation to indicate task context (e.g. @phone ), project (e.g. +GarageSale ) and priority (e.g. (A) ).

A todo.txt file might look like the following:

(A) Thank Mom for the meatballs @phone
(B) Schedule Goodwill pickup +GarageSale @phone
Post signs around the neighborhood +GarageSale
@GroceryStore Eskimo pies

A search and filter for the @phone contextual items would output:

(A) Thank Mom for the meatballs @phone
(B) Schedule Goodwill pickup +GarageSale @phone

To just see the +GarageSale project items would output:

(B) Schedule Goodwill pickup +GarageSale @phone
Post signs around the neighborhood +GarageSale

There are three formatting rules for current todo's.

Rule 1: If priority exists, it ALWAYS appears first.

The priority is an uppercase character from A-Z enclosed in parentheses and followed by a space.

This task has a priority:

(A) Call Mom

These tasks do not have any priorities:

Really gotta call Mom (A) @phone @someday
(b) Get back to the boss
(B)->Submit TPS report

Rule 2: A task's creation date may optionally appear directly after priority and a space.

If there is no priority, the creation date appears first. If the creation date exists, it should be in the format YYYY-MM-DD.

These tasks have creation dates:

2011-03-02 Document +TodoTxt task format
(A) 2011-03-02 Call Mom

This task doesn't have a creation date:

(A) Call Mom 2011-03-02

Rule 3: Contexts and Projects may appear anywhere in the line after priority/prepended date.

  • A context is preceded by a single space and an at-sign (@).
  • A project is preceded by a single space and a plus-sign (+).
  • A project or context contains any non-whitespace character.
  • A task may have zero, one, or more than one projects and contexts included in it.

For example, this task is part of the +Family and +PeaceLoveAndHappiness projects as well as the @iphone and @phone contexts:

(A) Call Mom +Family +PeaceLoveAndHappiness @iphone @phone

This task has no contexts in it:

Email SoAndSo at [email protected]

This task has no projects in it:

Learn how to add 2+2

Complete Tasks: 2 Format Rules

Two things indicate that a task has been completed.

Rule 1: A completed task starts with an lowercase x character (x).

If a task starts with an x (case-sensitive and lowercase) followed directly by a space, it is marked as complete.

This is a complete task:

x 2011-03-03 Call Mom

These are not complete tasks.

xylophone lesson
X 2012-01-01 Make resolutions
(A) x Find ticket prices

We use a lowercase x so that completed tasks sort to the bottom of the task list using standard sort tools.

Rule 2: The date of completion appears directly after the x, separated by a space.

For example:

x 2011-03-02 2011-03-01 Review Tim's pull request +TodoTxtTouch @github

If you’ve prepended the creation date to your task, on completion it will appear directly after the completion date. This is so your completed tasks sort by date using standard sort tools. Many Todo.txt clients discard priority on task completion. To preserve it, use the key:value format described below (e.g. pri:A)

With the completed date (required), if you've used the prepended date (optional), you can calculate how many days it took to complete a task.

Additional File Format Definitions

Tool developers may define additional formatting rules for extra metadata.

Developers should use the format key:value to define additional metadata (e.g. due:2010-01-02 as a due date).

Both key and value must consist of non-whitespace characters, which are not colons. Only one colon separates the key and value.

todo.txt's People

Contributors

karbassi avatar nelsonblaha avatar vorburger avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

todo.txt's Issues

Completion date: after `x` or after priority?

In the main section there is this picture:
image
.. which seems to suggest that the completion date goes after the (optional) priority, so a completed todo with both creation and completion dates would look like:

x (A) 2020-12-27 2020-12-27 Call nicoletta @phone t:2020-12-27 

However, later on, in the final remarks on completion dates it says that:

The date of completion appears directly after the x, separated by a space

And this example is given:

x 2011-03-02 2011-03-01 Review Tim's pull request +TodoTxtTouch @github

Should the image in the main section be clarified? Am I missing something?

Cheers

Storing configuration options inside todo.txt file

I'm looking for a way to store some configuration options in todo.txt file itself.

Several apps already have support for the h tag, so I think that we can use hidden tasks to define configuration options while maintaining compatibility with the current todo.txt v1 specification. For example, here's how options could be defined using the config tag:

// With JSON-like option format
h:1 config:{"title":"myTodoFile"}
h:1 config:{"colored-projects":{"project1":"#eee","project2":"#ccc"}}

// Or INI-like option format
h:1 config:title=myTodoFile
h:1 config:colored-projects=project1,#eee;project2,#ccc

Is there any todo.txt app that follows this approach?

Priority Can Include Characters Description Does Not State It Can Include

I think I may have found either a bug or a missed opportunity for data validation.

Creating a task with (A-) as the priority seemed to work -- it's stored that way, it's prioritized just under 'A', etc.

However, the stated requirements are one English alphabet letter, A-Z, uppercase only. So this probably is unintentional.

(Having said that, when I did see that (A-) worked, I was pleased as punch about the idea we could divide things more finely that way -- however, A+ comes 'after' A. So I figure it's probably unintentional behavior. It'd be neat if it did do 'plus and minus', but I understand that might run counter to the minimalist nature of the tool, too. So not requesting that by any means, but if it's interesting enough to anyone to run with, I wouldn't be unhappy about it.)

(Also, I'm not 100% sure if this should be under the CLI. I haven't tested it with any other interfaces, but I have no idea if they're doing validation above and beyond or what. Sorry if this is in the wrong place!)

todotxt.js - TodoList.prototype.checkTerm logic is faulty

Towards the end of the function on line 677, the if statement reads:

if (!case_sensitive) {
res = (task.text.indexOf(term) === -1) ? not : !not;
} else {
res = (task.text.toLocaleLowerCase().indexOf(term.toLocaleLowerCase()) === -1) ? not : !not;
}

It should actually read if(case_sensitive) - drop the !

You only want to convert to lower case if case_sensitive = false.

Ambiguity in the current todo.txt "spec"

The current spec of the todo.txt format (I'm referring to the README.md in this repo) contains several ambiguities, as is shown by some issues, e.g.

It would greatly help to have a precise, unambiguous specification. This way, programs can interoperate better which each other. It should not be too hard to make one, since the format seems quite simple. IMO, the current situation is quite bad, the README.md gives a general overview about the todo.txt format, but there are things left unspecified and things that contradict each other.

This is of course a different issue from the issue talking about versioning.

Multi-line tasks

I really don't like the idea that a single task must be on one line only. It makes it very inflexible which is in stark contrast to the todo.txt is just a text file thing.

When a task gets longer it becomes unreadable, especially if you don't like using text wrapping in your editor.
Some examples:

(A) Figure out why this doesn't work: (code was just pasted in)
    for (let ... {
    }

(B) Fix this error message: (message was just pasted in)
    Assertion failed: 
    bla bla bla...

(C) This is a very simple bullet list consisting of things
    I don't want to be individual tasks:
    - asdf
    - asdf
    - asdf

(D) I think that word wrapping is a property of the text and not the
editor, so I want to add the word breaks in myself and not have
to rely on a editor/client to do it for me.

(E) 2000-01-01 2000-01-02 rec:12d-1m @asdf +qwerty
I can use the first line for the 'metadata' and keep the actual task
nice and clean.

There should be some way to add multi-line support in a simple, mostly backwards-compatible way. Off the top of my head (though this isn't exactly backwards-compatible):

(A) this is a single task
(B) this is another single task

---
(C) A task enclosed between lines only consisting of dashes
is treated as a
multi-line task.
---

---
(D) this is another
multi-line
task
---

(D) this is a single task
(D) this is a single task

---
(D) 2000-01-01 2001-01-01 rec:12d-1m +my_project

This is another long task I want to be split off into multiple
lines to make it readable. Maybe I might throw in some simple
bullet list:
  - asdf
  - asdf
  - asdf
---

todo.txt syntax should include a "comment rule"

From @polvoazul on September 27, 2016 6:17

I thing we should be able to add lines to todo.txt that are not going to be parsed as a task.
There are two main advantages to that:

  1. This could be used to write comments, that could range from simple file section separators to editor (such as VIM) hints.
  2. We could use these comments to store non-task data such as a list of projects, or saved filters, or anything else the imagination wants. It would be easy to extend the format by using this.

I suggest the following syntax:

Any line starting with "# " is a comment, and should not be treated as a task. It should not count towards task numbers and should be, by default, ignored by the clients.
Each comment can also have a tag, that must be written like this # {tag}:. This tag means that specific clients can take advantage of that comment to provide additional functionality. A suggestion of a tag would be proj, such that we could drop a line in our todo.txt:

# proj: +buyGuitar +researchNewMusic ...

and tools could keep this projects 'alive' even without any tasks assigned to them.

Something like:

# filter: arts="+music OR +art OR +buyGuitar"

could be used by a client to save a named filter. Possibilities are endless!

I suggest tags are kept very small to keep things uncluttered.
Clients that don't understand a tag must simply discard that line as a comment.

I think todo.txt format is great, but it lacks a little bit of flexibility and I think this extension would enable clients to implement features without breaking other clients!

What do you guys think?

Copied from original issue: todotxt/todo.txt-cli#190

Start task with @context

From @bjorngi on December 14, 2014 0:10

According to the specifications of todo.txt format all context must be preceded with a space, but if you start a task with a context, does this rule apply to this? Or is @work call This Dude about+theAwesomeProject a valid task?

Copied from original issue: todotxt/todo.txt-cli#149

Spec should specify an encoding

The spec should include the expected encoding of a proper todo file. At the moment a client cannot properly open a todo.txt file created on a system with a different encoding.

There are two ways to fix this:

  1. Include encoding metadata in the todo.txt file
  2. Specify UTF-8

My preference would definitely be number 2.

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?

key-value pairs starting with numerics

Came up in #69 from @xsrvmy

Can/should keys be allowed to start with a number, i.e. 0-9? Current spec https://github.com/todotxt/todo.txt#additional-file-format-definitions implies this is currently allowed:

Developers should use the format key:value to define additional metadata (e.g. due:2010-01-02 as a due date).

Both key and value must consist of non-whitespace characters, which are not colons. Only one colon separates the key and value.

@rachmadaniHaryono recommends against using numbers which I concur with. However I'd go as far as saying the spec needs clarification here as this conflicts with how most people write times down, e.g. 11:00am doesn't seem to me to be a useful key of "11" and value of "00am".

Add a directory of test cases

What makes the todo.txt format amazing is the open-source and open-standard of it. There are so many tools written around the format ranging from shell to python to node and everything in between.

The todotxt-cli has a directory of tests that it runs to make sure all cases work. I propose that we create a directory of tests with *.in and *.out files. This allows tool developers to use whatever test framework they want as long as when a *.in file runs through their tool, the *.out matches their output.

Example

0000-add.in

add notice the daisies

0000-add.out

1 notice the daises
TODO: 1 added.

Thoughts and comments welcome.

Why is creation date more important than due date?

The way the format is now, and by the way I've always loved the idea of it, but I do have an issue with the only required date on each line being the creation date. When I sort my tasks, the creation date isn't terribly important. I have tasks that are categorized as someday that have been there for months. What's much more important are the things that need doing now, not things I thought of doing a long time ago. What I look at every single day is when a task is due. So before making a proposal for version 2 which a lot of people are doing here recently I'd like to know what the rationale behind putting so much importance on creation date over due date is? And suggest two of many possibilities that would elevate the importance of due dates without discarding previous todo list information.

Option 1: Creation dates just aren't that important, replace them with due & completion dates

  • Replace incomplete task lines' dates (which are currently creation dates) with due dates
  • Same rules for due dates as creation dates have now
  • When complete:
    • Completion dates still come first after the x tag like they do now
    • Completion date replaces the due date that was optionally there when the task was incomplete
    • Only the completion date is required to follow the completion tag x
  • Same rules everywhere else

Incomplete Tasks without due dates:

(A) Do something
Do something else created:2012-12-08

Incomplete Tasks With Due Date:

(A) 2012-12-12 Do something 
2012-12-12 Do something else created:2012-12-08

Complete Task With Completion Date Replacing Due Date:

x 2012-12-13 Do something 
x 2012-12-13 Do something else created:2012-12-08

Option 2: Allow two dates for both complete & incomplete tasks because creation dates are as important as due dates

  • Creation dates can appear alone as the first date, either as the first token in a line or after priority, just like they do now
  • A due date can prepend the creation date so that the due date is either the first token, or the token directly after a priority
  • When a task is complete it would look exactly the way it does now
    • An x tag to mark completion
    • A completion date that has replaced the due date if there was one
    • A creation date that follows the completion date
    • Priority has been removed from the initial tags as it usually is upon completion

Incomplete task without creation or due dates:

Do something unimportant
(A) Do something important

Same task with creation dates:

2018-02-10 Do something unimportant
(A) 2018-02-10 Do something important

Same tasks with due dates & creation dates:

2018-02-14 2018-02-10 Do something unimportant
(A) 2018-02-14 2018-02-10 Do something important

Same tasks when marked complete:

x 2018-02-15 2018-02-10 Do something unimportant
x 2018-02-15 2018-02-10 Do something important

Personally I prefer option 1 because it is just a cleaner implementation, and easier to read. If creation date is important enough to track, then I'd argue it's not as important as due date and can always be tracked using a key:value tag like created:2018-02-10. But if both are to be treated as important requirements option two works and is somewhat backwards compatible because although older apps will read the creation date as part of the task description when they're incomplete, it doesn't discard any information and the tasks would still be sortable by the creation date by sorting through the first word of the description tag.

But ultimately I'd like to see a specification that treats a todo list more like a todo list, by giving due dates at least as much if not more importance than creation dates. Creation date is almost metadata in a sense because it's information you use when analysing how well you're getting things done in a timely fashion, not data that helps you focus on what's important now. And I'd like to know why creation date was given so much relative importance when the spec was created and how creation dates are important to different developers working with this format?

Layout Image incorrect on location of priority

Completed Task, Rule 2 states

The date of completion appears directly after the x, separated by a space.

In the layout image in the format rules section, the priority is shown between the x and the completion date when the rule states otherwise. Should be

x 2016-05-20 (A) 2016-04-30 measure space for +chapelShelving @chapel due:2016-05-30

The format should allow for adding URLs

Currently, adding an URL such as https://example.com/url will be interpreted as a key-value pair and something like url:https://example.com/url is also not valid because:

Both key and value must consist of non-whitespace characters, which are not colons. Only one colon separates the key and value.

Being able to refer to URLs is crucial for me (and surely for many others), so I believe the format should allow for it (and make it easy).

Should there be a recommended priority count?

The priority is an uppercase character from A-Z enclosed in parentheses and followed by a space.

Usually todo apps have 3-5 levels of priority. 26 of those seems like an overkill. Maybe there should be a recommended (not enforced) limit?

Version 3.0.0 Spec - My vision of the new version todotxt

My vision of the new version todotxt.

File encoding format

"UTF-8 with BOM".

Line ending: Windows style (0x0D, 0x0A) - for more compatible.

Because "UTF-8" some times have problem with encoding detection (and incorrect definitions like ANSI (and damage to all characters)).

Version

Need add to format version in first line as tag.
Example: "{todotxt_version: 2.0}"

Due date

"due date has by far been the most-requested addition to the standard" link

Rename the "completion date" and "creation date" to the "start date" and "end date" (and changing function of course).

Because the "due:" tag became mandatory for each task (in my case), but I do not use "completion date" and "creation date".

Functions of "completion date" and "creation date" move to tags - "cm", "cr".

Tags

Also need to change the format of the tags.
In the current version they are very often misinterpreted and they can not contain a space.

Example:
"buy:apple,orange,banana" - I just forgot to put a space in my list and got the problem (stupid problem).

My variant: {tag_name} {tag_name:tag_value}

Why it is desirable to surround the tag with parentheses? - Because the people perception can skip (ignore) the text in parentheses.

Tags can place in any place (except "Marks completion"), also before Due date. (for compatibility with new marks priority format)

These symbols are used rarely enough that they can be "spent" on tags. (also tags can have spaces in the value, and looks like JSON).

Todo: need think through shield of character "{", "}", """, ":".

Date-time

Expand "date format" to "date-time format"! Example: 1917-10-01-23:59, 2018-02-07

What for? - Because it is very strange that the tool for working with tasks and time does not allow you to work with the exact time.

Hierarchy of projects

Support "\" in project name.

Example:

+bigwork conquest of Mars
+bigwork\stage1 launch rocket
+bigwork\stage1 launch car to Mars just for @fun +tesla\pr
+bigwork\stage2 launch human to Mars
+bigwork\stage3 ...
+bigwork\stage4 PROFIT

If the program supports hierarchical browsing:

bigwork
  stage1
  stage2
  stage3
  stage4

If the program program displays a flat list - it should place the projects side by side in the list (it's enough alphabetic sorting for this):

bigwork
bigwork\stage1
bigwork\stage2
bigwork\stage3
bigwork\stage4

Marks priority

Change from (A) to {1} - for compatibility with new tag format.

This will give 9 "basic" priorities {1}-{9} (in reality, few people use more than 5), and an infinite number of additional priorities {10}-{100..}.

(of course using only one tag that first)

Official list of tag

List:
1-9 - priority flags. {1}
10-999999999 - priority flags too. Max is {999999999}.
0 - no priority (programs must delete this tag from record). {0}
cr - creation date-time. {cr:2017-05-01}.
cm - complete date-time. {cm:2018-02-07-14:02}.
id - unique identificator (for automatic sync). {id:12345678}
hide - is hide record. {hide}.
base - hide and constant record for create a permanent project or context. {base}
color - just color of record (without specifying the way of implementation). {color=#FF0000}
crypt - is encrypted record. {crypt}. (encrypt options and other information is located at the beginning of the file in a special records).

See:
#8
https://docs.google.com/spreadsheets/d/11nqV2j8qc_O5SVsvkZ2JGZP98CABLQ6EwBxAQQi7Huc/edit#gid=0

Todotxt file example

For unit test and "make nice screenshots"

Work in progress...

making repositioning of context tag and project tag optional

I love to use todo.txt in a natural way of language:

discuss with @george about +superproject concerning the aspect of unicorns

This is in consensus with the todo.txt rules i read: "Contexts and Projects may appear anywhere in the line after priority/prepended date"

In my sleek this will show up like this, the sentence is destroyed

discuss with about concerning the aspect of unicorns @george +superproject

I fully respect that in your perspective this is not a bug but a feature.

I would like to use it without the feature of putting tags at the and of the line - perhaps there could be an option to switch this behaviour off?

Thanks!

Feature request: Option to change sorting order from priority to due date

Currently the sorting order is by priority and inside the priority sorting is by due date. I in contrary prefer sorting by due date and then by priority. So i can see all tasks on one concrete day ordered by priority. It would be nice, if this sorting order could be integrated as an option, too. Maybe with a button to change between both ordering types.

Adding support for date-time information using ISO8601

ISO8601 notation should be usable in all current date-only fields:
completion + creation date, and due date.

Currently the Todo.txt Spec only allows for calendar date precision, but most tasks are usually shorter than a whole day and can also have time sensitive deadlines.

example usage:

add ISO8601 support due:2018 <--  interpreted as 2018-01-01T00:00
add ISO8601 support due:2018-08 <-- interpreted as 2018-08-01T00:00
add ISO8601 support due:2018-08-25T17:15
add ISO8601 support due:2018-08-25T17:15:54.2980
add ISO8601 support due:2018-08-25T17:15Z <-- interpreted as 2018-08-25T17:15+00:00
add ISO8601 support due:2018-08-25T17:15+02
add ISO8601 support due:2018-08-25T17:15:54+02:00
add ISO8601 support due:2018-08-25T17:15:54.2980+02:00
  • Every date-time without a specified Timezone will be considered to be in the local system time zone.
  • Milliseconds can be arbitrarily precise.
  • Imprecise values will be floored to the earliest moment in time.
  • Applications should default to the 2018-08-25T17:15 format when automatically inserting entries.

Optional

Fault Tolerance

Add some resilience in the spec to compensate for human errors. For example the following isn't compliant (not even in the current todo.txt spec), but still unique.

add ISO8601 support due:2018-8-2
add ISO8601 support due:2018-08-25T17:15+2
add ISO8601 support due:2018-8-02T12:5
add ISO8601 support due:2018-8-02T12:05-0

Human readable Time zone codes instead of just offsets

Though there is some dispute about those codes, it would help with usage.
I suggest specifying the offical IANA abbreviations as canon (abbreviations would have to be extracted manually, or via a custom script).

examples:

2018-07-25T17:15UTC => 2018-08-25T17:15+00:00
2018-07-25T17:15CET => 2018-08-25T17:15+01:00
2018-07-25T17:15CEST => 2018-08-25T17:15+02:00

Import simple markdown checklists

I'd like that enhancement, think the title is pretty self explanatory.

Thanks!

Edit: If i see this right todotxt has no option for subtasks :(

example in README.md may not follow the format

sample todo.txt file:

(A) Thank Mom for the meatballs @phone
(B) Schedule Goodwill pickup +GarageSale @phone
Post signs around the neighborhood +GarageSale
@GroceryStore Eskimo pies

the last task does not comply with rule 3:

A context is preceded by a single space and an at-sign (@).

therefore, there are no contexts in the last task.

Key value pairs meta data clarification

PR #79 about "extra metadata tags" has some useful changes AND the discussion comments are also worth while recording in the readme.

PR has been closed, opened this to keep track and not lose it.

Todo.txt file example

Hello,

To test and make nice screenshots of applications it could be nice to have a complete todo.txt file example.

Support for non-latin or language independent markup

From @damascene on December 22, 2015 14:10

Most markups in todo.txt files (priority (A)(B) and Date t:, due:) depends on Latin characters so a user of other alphabets like Arabic, Russian, Chinese would have to switch keyboard to write the markup. It would be much easier for a user to write todo.txt tasks in his language letters without having to use Latin characters.

My thought is that many symbols that are available on every keyboard could be used like # & ^ +__()*&&{} [] and numbers could be used for priorities.

example for due: you can use:

Visit London {2015-12-22}

For completed tasks:

× Visit London

For priorities:

(1) Save my life
(2) Visit my mother

Copied from original issue: todotxt/todo.txt-cli#171

Multiple metadata values with the same key on the same task

I think that this is OK, according to the current spec:

2018-03-15 Multiple metadata values with the same key on the same task label:question label:invalid

Nothing in the spec currently says that the key names need to be unique in a single task. Is that everyone else's understanding, too? I know that widely-used keys like due and t are typically unique on a line, but I could see using metadata for other data like tag or with-person.

How deal with URI?

Hello,

It’s easy to ignore URL (ie https://) from keywords but how can we (parser writers) should deal with the others URI like mailto:, tel:, etc.?

Add more maintainers

There are several issues and PRs that are somewhat stalled due to lack of active maintainers. Would it be possible to give a few more people commit rights, @karbassi? That way the project could continue to evolve; otherwise, people may start looking into forking the repository, which IMO would be bad for the todo.txt ecosystem.

SVG mis-aligned under Mobile Firefox

https://github.com/todotxt/todo.txt/blob/master/description.svg isn't really usable under Android Firefox 103.2.0 (2022-08-03) in both mobile and desktop view as the bottom lines are not aligned correctly.

Chrome appears to be fine, as is Firefox desktop.

I'm unclear at this stage if this is an issue with the browser or the SVG (compliance for SVG is more than complicated). Possible solutions:

  1. revert to the previous PNG - ef02f1d
  2. use text only, a proposal in https://github.com/todotxt/todo.txt/pull/68/files - I do like the idea of a text based formatted having a text based specification :-)
  3. text from number 2 above and keep the SVG?
  4. something else?

Proposal for new todo.txt format - P4W

Hi,
I thought todo.txt needs a makeover and spent sometime to write up a new proposal for todo.txt, called P4W. Please read through and provide suggestions.

Thanks in advance -
p4w.pdf

(Moving pdf content into here - @karbassi 2020-01-07)

P4W

Priority, What, When, Who and Where

Premise: Tasks having context are way better than tasks which don’t, they can be categorized, group,
searched and analyzed based on these contexts.

But all contexts aren't created equal, then why should their prefixes be? And having defined
categories of contexts makes life easier. The task list should be easily enterable and readable by eye
with familiar symbols marking contexts.

The categories P4W - Priority, What, When, Who and Where.

n.n (pri) #action for +project with &person at @place on -today
1. (B) #email &john regarding the new design for +p4w -today

Priority:

Weight/Priority of this task.
(A), (B), (C), (D)

What: Project: prefix +

The project in which this task belongs. (one +)

Ex. +project, +p4w

What: Action: prefix #

Verb, Action item in the task. (two +s making a #)

Ex. #email , #call, #code, #analyze, #meeting

When: prefix -

Time bucket for this task.

Ex. -today, -week, -month, -backlog

Who: prefix &

Person involved in this task or delegated to. (you & who?)

Ex. &kaushik, &bill, &jane

Where: prefix @

Place where you want to do this task. (happens @ where ?)

Ex. @home, @work, @paris, @mall

Subtasks

Uses the id. Subtasks have a decimal part. All tasks between n and n+1 are subtasks of n.

Best said with an example.

2. (B) new year gifts
2.1 (B) #buy gift for &jane @mall
2.2 (B) #buy gift for &bill @walmart

Few other contexts which may be added to add value.

Effort prefix =

Track the effort spent on a task. = followed by an integer representing the denomination of your
choice, hours, days or pomodoros.

3. (B) #write doc for +p4w =2

Dependent tasks prefix !
A task which this task depends on.

4. (A) #ship documents to &jane +newapp !3

What is dropped.

Created Date Time.

It's really cumbersome to type in YYYYMMDD for each task you create and also the creation
date serves very little purpose.

Completed Date Time.

It's easier to add one date to the done.txt and list the tasks done under it rather than adding done
date to every other task. More readable.

Done.txt

20190101
X (A) #call &jane
X (B) #code +p4w demo @work =2
X (A) #call &dad @home
20190102
X (B) drop car for service
X (B) #email john about +p4w

Due

Due serves very little purpose unless you search the task list for the current date YYYYMMDD ,
the scheduling for such tasks must be done on an actual calendar application or reminders
which is more meant to do such jobs.

id:value

Again, they make the task line complex, less readable, all necessary purposes would be met by
P4Ws themselves.

Project and Context case sensitive

The spec is very clear on case sensitivity for:

it does not mention case for Project tags and Context Tags, however I think it is implied to be case sensitive and https://github.com/todotxt/todo.txt-cli/blob/master/todo.sh#L1031 is explicitly case sensitive when searching

In the Android apps I've experimented with, Project and Context are both case sensitive.

Any objections to documenting this explicitly?

Version 2.0.0 Spec

For version 2.0.0 to be released, we need to complete

  • Versioning specification - #6
  • Specify file encoding - #10

Specify recurrence as n-th day of week/month/year

I have gone through the specifications of todo.txt.
Can the recurrence of an event be specified as 1st Monday of every month?
Can there be a last date of recurrence (or date beyond which the recurring
event won't occur)?

Thanks.

Sorting and Color-coding

Awesome tool, but color-coding the projects and categories would be even cooler.
And sorting is a must ;-)
Thx a lot, if you’d manage to add that Stefan

Can key-value pairs appear anywhere in the line?

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

davx support

Hi,
I would have liked neither mode, local or webdav.
Davx integrates everything for me, so I don't have to take care of logins in apps, just have them integrate in the system tasks.
that way, when I migrate services, I just need davx switched, and all apps are fine.

Completion date: Optional or not?

The illustration of the todo.txt format states

Optional - Completion Date

while the definition of the format for complete tasks states that the completion date is required:

With the completed date (required), if you've used the prepended date (optional), you can calculate how many days it took to complete a task.

Therefore, is the "Optional" supposed to mean "depending on the completion status of the task" or is this a discrepancy? In particular, can a complete task omit its completion date?

Versioning todo.txt spec

With discussion and proposed changes to the todo.txt spec, the community will need a way to identify which version of the spec they are using.

There needs to be a way to identify to users and developers of tools the version of the spec they are using.

This issue is to discuss ways we could do that.

Priority B default color is not bold

EDIT: Wrong repository.


The default config values are:

export GREEN='\\033[0;32m'
export PRI_B=$GREEN

However, for consistency with the other priorities (which are bold), it should actually be:

export GREEN_BOLD='\\033[1;32m'
export PRI_B=$GREEN_BOLD

Set priority to C fails

It is weird that A, B work, but fails with C. Anything I can do? Is there a new version? I am in mac/homebrew

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.