Add priority

[thombruce]

Todo priority is the only missing compatibility feature with todo.txt. As usual, we won't worry about parsing from or restructuring to the todo.txt format right now, but we should be prepared to handle priorities from A-Z (26 possible priorities).

Some debate as to whether we simply store the alpha value or whether we should convert to sort of an enumerable (0-25 or 1-26).

I do know that we will want to represent priority with color somehow, perhaps intelligently picking a palette dependent on the range of letters used. I.e. A-D is only four colours, but the user might expect A to be high priority (red) and D to be low priority (yellow), with B and C being somewhere on the gradient in between.

---

The user should probably be able to enter this manually in the todo text input, just as they can with projects, contexts and tags, however we probably do not consider this part of the todo text and parse it out to store separately (unlike projects, contexts and tags). This may or may not be a later consideration, as we would like to eventually setup parsing for a full todo.txt line. While we presently do support all other features of todo.txt (e.g. done, created, completed), we do not presently parse these from the text input.

[thombruce]

Working the problem on a feat/priority branch. At present I've typed the priority attribute as a number, but should this be the case?

We want to support priorities of kinds:

• ([A-Z])
• pri:[A-Z]

Those above are the official and semi-official ways preferred by todo.txt. Also consider:

• priority:[A-Z] (key is unabbreviated)
• pri:[0-N] (value is numeric)
• pri:[Critical/High/Medium/Low] (value is some commonly used string, not sortable alphabetically)

Consider also that pri might not indicate priority at all, but could abbreviate something else entirely. This should also be an i18n concern.

[thombruce]

Assume that the key part is easily handled. Either the priority is early in the todo.txt string and denoted by parentheses, or the key is pri or priority. These should be easily recognised.

Given that a priority is denoted by parentheses, assume that the value is [A-Z].

Where priority is recognised by a key of either pri or priority, attempt to match one of the following patterns:

1. is A-Z
2. is 0-N
3. is one of Critical, High, Medium or Low

Store and sort accordingly, sorting the last set of values based on relationship to an enumerable.

---

Secondarily, assume that the user will use a consistent approach, at least per-document.

Prioritise support for A-Z, but if a value is numeric store it as a number.

As for Critical,High,Medium,Low, given that these are unsortable... consider one of the following approaches:

1. Group by priority and maintain a separate record of how to sort the groups into the appropriate order
2. Convert to and store a numeric value instead

The second approach is one we're considering for [A-Z] anyway, if only because integers have a lower storage requirement than strings. But it isn't that simple... We still require a way to know the preferred approach of the user, and if they use custom sets or add additional priorities, we require some way to update the numeric value in order to maintain sortability.

---

For now... treat pri: and priority: keys as though they were regular tags (they are), and maintain focus on ([A-Z]) denoting priority.

We still have to determine whether we store this as a number or a string, however.

Keep it simple. Keep it a string.

We will maintain a priority of A-Z and output this in the form of ([A-Z]) which will appear BEFORE the created date for incomplete todos and AFTER the done and created dates for completed todos.