A plain-text file format for todos and check lists(github.com)
github.com
A plain-text file format for todos and check lists
https://github.com/jotaen/xit
35 comments
With [x]it!, lexicographic sorting of lines works as well, as long as you stick to the following rules:
- Write due dates first (if you use due dates)
- Pad your priority with dots (if you use priorities)
- Don’t use line breaks within descriptions, so only single-line items
- Don’t use titles
That way, the lines will sort by checkbox status (open first), then by priority (highest first), and finally by due date (soonest first). For example:
- Write due dates first (if you use due dates)
- Pad your priority with dots (if you use priorities)
- Don’t use line breaks within descriptions, so only single-line items
- Don’t use titles
That way, the lines will sort by checkbox status (open first), then by priority (highest first), and finally by due date (soonest first). For example:
[ ] !!! -> 2022-05-01 Something
[ ] ..! -> 2022-06-15 Something else
[x] .!! -> 2022-01-04 More text> grep and sort tasks to make sense of things
This.
grep + sort + awk = unbelievable single person task management effectiveness. And it was right under my nose all the while.
I've dumbed my version even further, I just use numbers. every line starting with 1 is highest Priority and so on.
another important piece i needed was a pointer to where i last left off. I just use double underscores "__". next time just open and search for 2 underscores and start right off.
Works everywhere.
This.
grep + sort + awk = unbelievable single person task management effectiveness. And it was right under my nose all the while.
I've dumbed my version even further, I just use numbers. every line starting with 1 is highest Priority and so on.
another important piece i needed was a pointer to where i last left off. I just use double underscores "__". next time just open and search for 2 underscores and start right off.
Works everywhere.
Doug McIlroy recounts how early use of egrep for personal calendars led to Al Aho improving its algorithm: https://minnie.tuhs.org/pipermail/tuhs/2022-August/026336.ht...
Side note: for weekly personal todos and tasks, I have not found a better way than a whiteboard or a piece of paper stuck on the wall.
Paper on the wall is better in many ways (e.g. easy to rip off when guests are coming over, folds into the pocket to take it with you for shopping, scan it, etc)
I use plain text files for longer term tasks and todos. One file per project.
Paper on the wall is better in many ways (e.g. easy to rip off when guests are coming over, folds into the pocket to take it with you for shopping, scan it, etc)
I use plain text files for longer term tasks and todos. One file per project.
I like it. Few issues:
- doesn't describe handling spaces or other characters before the checkbox
- doesn't support UTF-8 checkbox emoji
- doesn't support nested lists
- specifies a specific space character when a character class would be better
- not clear what "item must not contain blank lines" means
- description indentation limit of four space characters is a problem for nested items
- description supporting blank lines (properly indented) would be useful for longer descriptions
- date should support an ISO or other standard date format
- timezone is necessary for events happening in specific timezones or across timezones> - doesn't support UTF-8 checkbox emoji
That's a good thing. Its also unicode, not utf-8. Your plugin can display it with a unicode character. Having a simple ASCII char set helps portability _a lot_. No benefit in supporting unicode code points.
> - doesn't support nested lists
If you can tick all items within a nested list, why bother writing it with dedicated TODO items? Additionally, you can just create more files for elaboration. Your file system is at your dispense. Additionally, that can be implemented in your plugin of choice. Goes with your first point in hand.
> - specifies a specific space character when a character class would be better
ASCII has no official character class. If your are refering to tabs; I don't think this is bad or good. Maybe you can follow uo on the use case..
> - not clear what "item must not contain blank lines" means
Probably that a blank line is used as a separator
> - description indentation limit of four space characters is a problem for nested items
I don't see why. The fixed amout of four characters obviously lines up to the start of the text from an item. This helps readability a lot. And is a simple standard for identation rules.
> - description supporting blank lines (properly indented) would be useful for longer descriptions
I disagree. A TODO list should be simple to grasp. Details and elaborations can be put in a dedicated directoy and refered to. Also, it is a _very bad_ idea to work with invisible lines. Users are dump and quick to judge.
> - date should support an ISO or other standard date format
This is the most portable standard, but extended for human editing..
> - timezone is necessary for events happening in specific timezones or across timezones
I tend to agree. But the person hosting the list should probably be the one defining the time zone. But I haven't read anythinf about time zones in the primer. Nothing stops one to simply append it to a time. No need for the standard to define such.
I think it is well put and the first one which checks all the boxes for me. Congratz to the author.
I don't see why such a comment is #1.
That's a good thing. Its also unicode, not utf-8. Your plugin can display it with a unicode character. Having a simple ASCII char set helps portability _a lot_. No benefit in supporting unicode code points.
> - doesn't support nested lists
If you can tick all items within a nested list, why bother writing it with dedicated TODO items? Additionally, you can just create more files for elaboration. Your file system is at your dispense. Additionally, that can be implemented in your plugin of choice. Goes with your first point in hand.
> - specifies a specific space character when a character class would be better
ASCII has no official character class. If your are refering to tabs; I don't think this is bad or good. Maybe you can follow uo on the use case..
> - not clear what "item must not contain blank lines" means
Probably that a blank line is used as a separator
> - description indentation limit of four space characters is a problem for nested items
I don't see why. The fixed amout of four characters obviously lines up to the start of the text from an item. This helps readability a lot. And is a simple standard for identation rules.
> - description supporting blank lines (properly indented) would be useful for longer descriptions
I disagree. A TODO list should be simple to grasp. Details and elaborations can be put in a dedicated directoy and refered to. Also, it is a _very bad_ idea to work with invisible lines. Users are dump and quick to judge.
> - date should support an ISO or other standard date format
This is the most portable standard, but extended for human editing..
> - timezone is necessary for events happening in specific timezones or across timezones
I tend to agree. But the person hosting the list should probably be the one defining the time zone. But I haven't read anythinf about time zones in the primer. Nothing stops one to simply append it to a time. No need for the standard to define such.
I think it is well put and the first one which checks all the boxes for me. Congratz to the author.
I don't see why such a comment is #1.
Sticking to ASCII in this day and age is nice and fun if English is your mother tongue, but it's a big middle finger to the rest of the world. Please don't.
Per specification, [x]it! files must be UTF-8 encoded. (See https://github.com/jotaen/xit/blob/main/Specification.md#fil...)
You can use Unicode characters in item descriptions, so you can write these texts in Japanese, Finnish, or Greek. Only the “syntactical elements” (like checkboxes, priority, due dates) are made up from ASCII characters, to ensure that they are easy to type.
You can use Unicode characters in item descriptions, so you can write these texts in Japanese, Finnish, or Greek. Only the “syntactical elements” (like checkboxes, priority, due dates) are made up from ASCII characters, to ensure that they are easy to type.
Perhaps the spec could allow an implementation to support a run-time option to recognize alternate characters for syntactic elements. This would have the downside that one person's data might not be shareable with another person's [x]it installation. But that's not necessarily a bug, especially to people who don't plan to share their todo lists.
This run-time-option-only approach would be much better than the "be liberal in what you accept and strict in what you emit" philosophy that tends to cause fragmentation on lots of different levels.
This run-time-option-only approach would be much better than the "be liberal in what you accept and strict in what you emit" philosophy that tends to cause fragmentation on lots of different levels.
> Perhaps the spec could allow an implementation to support a run-time option to recognize alternate characters for syntactic elements.
Please don't. The equivalent in programming languages would be localizing the syntactic elements ({}, (), [], '.', etc). Its much simpler for a language ecosystem to have the same syntax regardless of the programmer's language.
As far as I know, international keyboards can still type these characters just fine.
Please don't. The equivalent in programming languages would be localizing the syntactic elements ({}, (), [], '.', etc). Its much simpler for a language ecosystem to have the same syntax regardless of the programmer's language.
As far as I know, international keyboards can still type these characters just fine.
You are right, I didn't wanted to imply that these lists can only be used by speakers fluent in english.
I wanted to imply that grammars of languages are best represented in ASCII.
There are languages written from right to left or top to bottom. No standard I know of are supporting such flexibility in syntax. And it shouldnt be necessary - if the <user text> items within the grammar support unicode but the keywords are ASCII only it can MORE easily adapted than supporting unicode....
There are languages written from right to left or top to bottom. No standard I know of are supporting such flexibility in syntax. And it shouldnt be necessary - if the <user text> items within the grammar support unicode but the keywords are ASCII only it can MORE easily adapted than supporting unicode....
>>if English is your mother tongue
"mother or preferred"
-- I don't disagree with your basic point, but I like to be included :). There's a Lot of us around whose native / mother tongue is not English, but we prefer it for computing tasks (and frequently gaming / movies / entertainment too - Forums are littered with folks complaining of having to "enjoy" a horrible localized version of something, instead of the original English)
"mother or preferred"
-- I don't disagree with your basic point, but I like to be included :). There's a Lot of us around whose native / mother tongue is not English, but we prefer it for computing tasks (and frequently gaming / movies / entertainment too - Forums are littered with folks complaining of having to "enjoy" a horrible localized version of something, instead of the original English)
Thanks for sharing your notes. Nesting of items is not supported, although the idea has come up. It’s on hold right now – that’s mostly due to practical reasons, because it’s relatively hard to implement in tooling.
Allow me to clarify a few details regarding the spec:
- There can’t be any character before the checkbox. (An item “MUST start at the beginning of a line with a checkbox.”)
- A blank line is defined as “a line that is either empty, or that exclusively consists of blank characters”, and a blank character is defined as “a character from the Unicode Space Separator category (Zs)”. So the description text of an item (that can span multiple lines) cannot contain a line that’s all blank. Reason is that a blank or empty line separates item groups from each other, so allowing it to appear within descriptions could create visual ambiguity. (Even though it wouldn’t be ambiguous from a purely formal standpoint.)
- The format for dates is a subset of ISO-8601, except for the slashed variant (2020/12/31) that’s there for convenience, and the notation for quarters (2022-Q1).
Allow me to clarify a few details regarding the spec:
- There can’t be any character before the checkbox. (An item “MUST start at the beginning of a line with a checkbox.”)
- A blank line is defined as “a line that is either empty, or that exclusively consists of blank characters”, and a blank character is defined as “a character from the Unicode Space Separator category (Zs)”. So the description text of an item (that can span multiple lines) cannot contain a line that’s all blank. Reason is that a blank or empty line separates item groups from each other, so allowing it to appear within descriptions could create visual ambiguity. (Even though it wouldn’t be ambiguous from a purely formal standpoint.)
- The format for dates is a subset of ISO-8601, except for the slashed variant (2020/12/31) that’s there for convenience, and the notation for quarters (2022-Q1).
It would be simpler to just use the ISO date format. Otherwise people have to implement their own date parser for your stricter format, which adds code (and therefore bugs) and increases probability that people will incorrectly implement the spec.
Why wouldn't you allow space before the checkbox? If somebody accidentally has a space because it's not obvious in their editor (esp. if items can be separated by two newlines) what happens? Undefined behavior? Your format looks a lot like Markdown so I wouldn't have assumed this was a spec requirement unless I looked closely (most people don't look at specs closely)
Why wouldn't you allow space before the checkbox? If somebody accidentally has a space because it's not obvious in their editor (esp. if items can be separated by two newlines) what happens? Undefined behavior? Your format looks a lot like Markdown so I wouldn't have assumed this was a spec requirement unless I looked closely (most people don't look at specs closely)
> It would be simpler to just use the ISO date format.
[x]it! is supposed to be edited (editable) by hand, and from an end-user perspective, I personally find ISO-8601 in its entirety relatively complex to grasp. The currently supported date formats aim to be a tradeoff between “flexible enough” but “not too complex yet”.
> Why wouldn't you allow space before the checkbox?
To enforce a tidy layout of the file. Whitespace before the checkbox (i.e. on the same line) is undefined behaviour. The idea is that editor plugins help users with compliance of the rules. For example, I think that all available [x]it! editor plugins would highlight it if there was illegal whitespace in front of a checkbox.
[x]it! is supposed to be edited (editable) by hand, and from an end-user perspective, I personally find ISO-8601 in its entirety relatively complex to grasp. The currently supported date formats aim to be a tradeoff between “flexible enough” but “not too complex yet”.
> Why wouldn't you allow space before the checkbox?
To enforce a tidy layout of the file. Whitespace before the checkbox (i.e. on the same line) is undefined behaviour. The idea is that editor plugins help users with compliance of the rules. For example, I think that all available [x]it! editor plugins would highlight it if there was illegal whitespace in front of a checkbox.
Some of your comments are described in the extended syntax specifications[0].
[0]: https://xit.jotaen.net/syntax-guide
[0]: https://xit.jotaen.net/syntax-guide
For a standalone CLI, I still prefer https://github.com/todotxt/todo.txt-cli - probably because there are Android and iOS clients for it, and it's based around a bash script.
For vim, I just use vim-wiki, which is a superset of this functionality.
Of course, looking through this thread, there's lots of different options. Which is cool.
For vim, I just use vim-wiki, which is a superset of this functionality.
Of course, looking through this thread, there's lots of different options. Which is cool.
I like this a bunch. I've used `-` to represent at task that isn't done and `+` to represent a task that is done, optionally with a time estimate in front of them. I might switch over to this since it's just a bit more descriptive and defined.
I do exactly the same, and also use a tilda for tasks in progress, and 2 periods for those that are blocked. Sometimes simpler is better.
I am almost using this format for my markdown todo app written in Ruby:
https://github.com/coezbek/rodo
Differences:
I use unicode symbols such as ⌛ or for paused or priority items.
I use dash for obsolete/canceled items. I find this more in line with bullet journal which inspired the development of Rodo.
I do use markdown bullet lists because I like to indent and order stuff.
Rodo is organized primarily around showing the todos of a day (mostly today) and provides the tools to postpone or carry-over todays to another day.
https://github.com/coezbek/rodo
Differences:
I use unicode symbols such as ⌛ or for paused or priority items.
I use dash for obsolete/canceled items. I find this more in line with bullet journal which inspired the development of Rodo.
I do use markdown bullet lists because I like to indent and order stuff.
Rodo is organized primarily around showing the todos of a day (mostly today) and provides the tools to postpone or carry-over todays to another day.
rodo looks quite cool! It’s interesting to see how common the syntax is with these formats, so there seem to be “natural” patterns.
[x]it! doesn’t try to be opinionated about what you use it for. So you could use it for your daily todos, but you could also use it for writing a packing list, or maintaining a wish list with potential shopping items. It’s intended to be a generic file format, and more specific use-cases could be supported through (independent) tooling.
[x]it! doesn’t try to be opinionated about what you use it for. So you could use it for your daily todos, but you could also use it for writing a packing list, or maintaining a wish list with potential shopping items. It’s intended to be a generic file format, and more specific use-cases could be supported through (independent) tooling.
Discussion from a few months ago: https://news.ycombinator.com/item?id=30879327
TaskTXT (https://tasktxt.com/) looks to be a really interesting product in this space
The creator made a few videos on the motivation & implementation of it. He goes into such great detail in crafting subtle almost unnoticable animations in the app.
- https://www.youtube.com/watch?v=kZdBgVZn5NI - https://www.youtube.com/watch?v=JjKxpks13Zw
The creator made a few videos on the motivation & implementation of it. He goes into such great detail in crafting subtle almost unnoticable animations in the app.
- https://www.youtube.com/watch?v=kZdBgVZn5NI - https://www.youtube.com/watch?v=JjKxpks13Zw
Why not Orgmode? I've been using it on multiple devices without any problems.
I still occasionally edit it as text (when I'm on a machine without Emacs/Orgzly).
I still occasionally edit it as text (when I'm on a machine without Emacs/Orgzly).
Have you found a good way to use org-mode on your phone?
I remember trying to find a suitable app for weeks, but without any success.
Even simple things, like following links into other files, were not possible.
Edit: Ah, I missed you mentioning Orgzly. Last time I used it, I had a lot of trouble with syncing due to its way of storing files in a notebook. Everytime I deleted a file on any other device, Orgzly would just recreate the file and sync it back to all other devices. And when I tried it, it didn't support links to org-IDs.
Even simple things, like following links into other files, were not possible.
Edit: Ah, I missed you mentioning Orgzly. Last time I used it, I had a lot of trouble with syncing due to its way of storing files in a notebook. Everytime I deleted a file on any other device, Orgzly would just recreate the file and sync it back to all other devices. And when I tried it, it didn't support links to org-IDs.
Must mention Logseq. Logseq support org-mode as first class format.
https://trello.com/c/z651hP7v/1116-org-mode-support
I don't think Logseq has realized how this feature can win popularity, since you can't find anything on org-mode in their website. (Always markdown, LOL)
I like orgzly but in my opinion orgro is even better. I think a critical point of usability with mobile has been met with org mode.
Orgzly with Syncthing has been my setup for years.
Honestly people wanting to make a hobby project from scratch and then brag about it in a blog post to make themselves look like a more savy programmer/techie (hey, not blaming people, when it is done well it is way better than a resume with bullet points) is primarily the reason they dont use org mode. It is like wondering why people go through massive amounts of efforts to bake stuff from scratch when there is a super market and bakery down the street, except it is also like I said a resume.
If you want a plain text organizational, compositional and scheduling tool that you can use for the rest of your life and know that 30 years down the line it will be actively supported, developed and you will be able to tweak anything you want.... emacs/org mode is by far and away the best choice. It isn't even remotely close, we are talking about the difference between a planet and a tiny asteroid when you compare org mode to other plain textish organizational, compositional and scheduling tools.
For as long as humanity doesn't collapse and probably even after it does org mode and emacs will be used (there is going to be some nerd somewhere using org mode and ledger cli to meticulously track how many smoked rats and cockroach kebobs they have left to eat before they have to leave their bunker), there is just such an intense critical mass of utility under an open source license.
About the only bad thing with org mode at this point is it has such a vast nexus of interconnected capability it is difficult to even describe what exactly it is anymore lol. Like how would you even adequately describe org mode in a single sentence? It would have to be a Thomas Pynchon style sentence lol.
If you want a plain text organizational, compositional and scheduling tool that you can use for the rest of your life and know that 30 years down the line it will be actively supported, developed and you will be able to tweak anything you want.... emacs/org mode is by far and away the best choice. It isn't even remotely close, we are talking about the difference between a planet and a tiny asteroid when you compare org mode to other plain textish organizational, compositional and scheduling tools.
For as long as humanity doesn't collapse and probably even after it does org mode and emacs will be used (there is going to be some nerd somewhere using org mode and ledger cli to meticulously track how many smoked rats and cockroach kebobs they have left to eat before they have to leave their bunker), there is just such an intense critical mass of utility under an open source license.
About the only bad thing with org mode at this point is it has such a vast nexus of interconnected capability it is difficult to even describe what exactly it is anymore lol. Like how would you even adequately describe org mode in a single sentence? It would have to be a Thomas Pynchon style sentence lol.
I used "lol" twice in very close proximity, I am sorry.
How does this compare with TaskPaper, like https://guide.taskpaper.com/getting-started/? TaskPaper is sophisticated enough that OmniFocus can use it as a serialization format.
I’ve never used TaskPaper, but the capabilities of the data format look somewhat similar.
I think the difference is primarily a philosophical one: [x]it! is a file format with a formal specification that’s open source.[1] There is no “canonical” tool for it, the idea is rather that tools can be created separately. That should give users the freedom to work with their data independent of specific tools.
[1] https://github.com/jotaen/xit/blob/main/Specification.md
I think the difference is primarily a philosophical one: [x]it! is a file format with a formal specification that’s open source.[1] There is no “canonical” tool for it, the idea is rather that tools can be created separately. That should give users the freedom to work with their data independent of specific tools.
[1] https://github.com/jotaen/xit/blob/main/Specification.md
That's fair. I could've sworn that TaskPaper was an actual spec, but when looking just now I couldn't find it.
The maintainer wrote something about this here: https://support.hogbaysoftware.com/t/where-is-taskpapers-fil...
I saw that, and neither of those repos have been updated in the last 6 years. (Maybe they're still up to date? I have no idea.)
Why use this over orgmode?
do you use orgmode outside of emacs? I tried a port to vscode once and it was not usable.
Org is becoming more accessible outside of Emacs. A handful of us are working on it.
I built two apps for iOS:
https://flathabits.com
https://plainorg.com
There are other org-based tools out there.
https://BrainTool.org
https://logseq.com
https://orgzly.com
https://beorg.app
https://easyorgmode.com
https://organice.200ok.ch
https://orgro.org
I built two apps for iOS:
https://flathabits.com
https://plainorg.com
There are other org-based tools out there.
https://BrainTool.org
https://logseq.com
https://orgzly.com
https://beorg.app
https://easyorgmode.com
https://organice.200ok.ch
https://orgro.org
> do you use orgmode outside of emacs?
Outside... of emacs? You leave emacs?
Outside... of emacs? You leave emacs?
I like EasyOrg as you do not need to use Emacs. It also has a useful agenda.
[1] https://www.easyorgmode.com
[1] https://www.easyorgmode.com
I use beorg on iOS, and orgzly on android
I never use it with emacs. Only other text editors and orgzly.
It's a fine standard.
It's a fine standard.
Taskwarrior uses a pain text format and is excellent. It's my daily driver todo list. https://taskwarrior.org
An online site that does task warrior sync - https://inthe.am
No way to create subitems i.e. when the subitems are completed, the parent item is completed? The main thing I need out of a task manager is for it to allow me to decompose and refine tasks, and to keep track of that stuff as it gets complicated. If the data format doesn't even allow for subtasks, that seems impossible without abusing tags.
edit: I now see that it's the top issue on your bugtracker.
edit: I now see that it's the top issue on your bugtracker.
For reference, this is the discussion around subitems / nesting: https://github.com/jotaen/xit/discussions/2
As mentioned in that ticket, I’m still reluctant to add this to the [x]it! file specification. On the one hand it seems like an obvious and useful feature, but on the other hand it’s unfortunately pretty difficult to implement in tooling. For example, I tried to add experimental support for nested subitems in the Sublime Text plugin, but I eventually had to give up, just because the syntax highlighting engine is so limited in regards to recursion. It’s the same – or much worse – for other editors.
At the end of the day, I feel that it doesn’t help to add such a feature to the file format, if tools then cannot deal with it properly. Right now, the spec is so simple that it can be implemented in maybe a day or so. I see a great deal of value in keeping the hurdle for tool creators small. But it’s a pretty tricky balancing act in the end.
As mentioned in that ticket, I’m still reluctant to add this to the [x]it! file specification. On the one hand it seems like an obvious and useful feature, but on the other hand it’s unfortunately pretty difficult to implement in tooling. For example, I tried to add experimental support for nested subitems in the Sublime Text plugin, but I eventually had to give up, just because the syntax highlighting engine is so limited in regards to recursion. It’s the same – or much worse – for other editors.
At the end of the day, I feel that it doesn’t help to add such a feature to the file format, if tools then cannot deal with it properly. Right now, the spec is so simple that it can be implemented in maybe a day or so. I see a great deal of value in keeping the hurdle for tool creators small. But it’s a pretty tricky balancing act in the end.
I came up with this format 10 years ago to document running our regression test. It was a complicated process (for reasons) and I had four major sections---one outlining items to do once, such as:
When I came up with this system, I didn't know about ORG mode. Nor did I expect anyone to use a tool other than a text editor with this. Heck, a person could print this out and use a pen to mark items off the list.
[ ] Check you can log into Jenkins
[ ] Check you have an account on lab1
[ ] SSH into account on lab1
[ ] "mkdir bin"
[ ] "mkdir conf"
[ ] "mkdir var"
[ ] In shell configuration file, export following
[ ] export FOOBAR=...
[ ] export PATH=$PATH:$FOOBAR/bin:$FOOBAR/install
[ ] export LD_LIBRARY_PATH=$FOOBAR/lib64b:$LD_LIBRARY_PATH
[ ] Ensure you can run "sudo -u root foo"
[ ] Ensure you can run "sudo -u nobody bar"
[ ] Check you have an account on lab 2
[ ] SSH into account on lab2
[ ] ...
When I came up with this system, I didn't know about ORG mode. Nor did I expect anyone to use a tool other than a text editor with this. Heck, a person could print this out and use a pen to mark items off the list.
It's mostly the lack of nesting that convinced me not to use xit and to make my own format: http://richardmavis.info/does-the-world-really-need-another-...
And I'm curious about nesting being "pretty difficult to implement in tooling"---how do you mean? At least with emacs I found it no more difficult than counting whitespace characters: https://git.sr.ht/~rfm/tdtd-mode/tree/master/item/readme.md
And I'm curious about nesting being "pretty difficult to implement in tooling"---how do you mean? At least with emacs I found it no more difficult than counting whitespace characters: https://git.sr.ht/~rfm/tdtd-mode/tree/master/item/readme.md
I’ve tried to implement the item nesting in the [x]it! Sublime Text plugin. The problem there was that I didn’t manage to implement strict rules for subitems. If you consider the following example:
- The “Another Sub-Sub Item” should not be allowed, because it skips one level (from the first to the third, instead of to the second).
- The “Continuation of the first item’s description” should not be allowed, because it only makes sense for sub-items to appear after an item’s description, but not in between.
- It also doesn’t seem to be possible for sub-items to inherit their parent’s status, e.g. if the parent is checked, to also colour the sub-item as if it was checked.
[x] Example item
[ ] Subitem
[ ] Another Sub-Sub Item
Continuation of the first item’s description
- The “Another Sub-Sub Item” should not be allowed, because it skips one level (from the first to the third, instead of to the second).
- The “Continuation of the first item’s description” should not be allowed, because it only makes sense for sub-items to appear after an item’s description, but not in between.
- It also doesn’t seem to be possible for sub-items to inherit their parent’s status, e.g. if the parent is checked, to also colour the sub-item as if it was checked.
Oh, interesting. When you put it that way---"Example item" and "Continuation ..." being the same semantic unit---I see the problem. And why nesting is easier to implement when the semantics are based on lines.
I think it's also interesting the way you say "The “Another Sub-Sub Item” should not be allowed". Seems to me the format and tooling should do what the user wants and expects, or at least try to. Why not allow it if the user wants it that way?
I think it's also interesting the way you say "The “Another Sub-Sub Item” should not be allowed". Seems to me the format and tooling should do what the user wants and expects, or at least try to. Why not allow it if the user wants it that way?
I realised that I made a small mistake in my code sample above, but I can’t edit the post anymore. It should have been:
The “Another Sub-Sub Item” wouldn’t make sense in my mind, because the idea is that the text maps to well-defined data structures, in this case a tree structure. So an item can have child items, which each can have child items, and so on. However, “Subitem” doesn’t have direct child items.
I find this restriction important, because it would allow to parse the text into relatively simple programmatic models.
[x] Example item
[ ] Subitem
[ ] Another Sub-Sub Item
Continuation of the first item’s description
The “Another Sub-Sub Item” wouldn’t make sense in my mind, because the idea is that the text maps to well-defined data structures, in this case a tree structure. So an item can have child items, which each can have child items, and so on. However, “Subitem” doesn’t have direct child items.
I find this restriction important, because it would allow to parse the text into relatively simple programmatic models.
> The “Another Sub-Sub Item” wouldn’t make sense in my mind, because the idea is that the text maps to well-defined data structures, in this case a tree structure. So an item can have child items, which each can have child items, and so on.
I get it :) and that's how I implemented mine too: https://git.sr.ht/~rfm/tdtd-parser/tree/master/item/tdtd.jan...
> However, “Subitem” doesn’t have direct child items.
I'm not sure if the difference in our approaches is philosophical or practical. Why shouldn't "Another Sub-Sub Item" be considered a direct child? What if the user added the extra spaces unintentionally? What if, just for fun, they wanted to indent their list like:
I get it :) and that's how I implemented mine too: https://git.sr.ht/~rfm/tdtd-parser/tree/master/item/tdtd.jan...
> However, “Subitem” doesn’t have direct child items.
I'm not sure if the difference in our approaches is philosophical or practical. Why shouldn't "Another Sub-Sub Item" be considered a direct child? What if the user added the extra spaces unintentionally? What if, just for fun, they wanted to indent their list like:
[x] Example item
[ ] Subitem
[ ] A Sub-Sub Item
[ ] A Sub-Sub Item
[ ] A Sub-Sub Item
Continuation of the first item’s description
> There can be conflicting state, for example: what happens if the parent item is checked, but the children are still open? Or the other way around? If all children are checked, shouldn’t that “automatically” resolve the parent? What if the parent has a closer due date than the children? And so on. While decision could be made for any of these corner cases, it might still feel strange in practice.
To me, the convention to go with seems easy.
1) If the parent is explicitly checked, leave the children as they are, and ask the user through tooling if they want to check each unchecked subtask, delete it, or move it up a level.
2) If all of the children are checked, the parent stays unchecked, but tooling should ask the user if the parent is complete, or if another subtask should be added.
3) If the parent has a closer due date than the children, don't do anything unless you feel like warning the user i.e. hold the subtasks to their due dates, and hold the parent task to its due date.
The issue about descriptions I see as a non-issue: dictate that descriptions marry to the task above them. It would be nicer to be freer with mixing descriptions and tasks, but you'd have to introduce more tokens.
One thing in the thread that I don't find necessary is marking partial completion.
I don't have any experience with Sublime, but this seems like a very basic tree.
When reading the subtasks, all you have to hold is the stack of the checkbox states and due dates of higher task levels for tooling to answer any of the above questions. A tool could seek backwards in order to check a parent if the children were checked, the user was warned, and the user said they wanted the parent checked. But if instead you really only wanted to read a line at a time, you could add a dummy item called "[ ] Complete parent task" at the end of the subtask list in order to keep an unchecked parent with checked children consistent.
The problem for me is that a tree is what I have trouble organizing. If it's just a linear list of things, I'm not sure how useful it could be for me other than by setting alarms that I could set directly. There is never a time when one of my tasks isn't to break down another task into simpler steps; all but the simplest tasks I have really have "break this down" that as the default first subtask.
So one workflow datapoint for useful with subtasks, useless without subtasks.
To me, the convention to go with seems easy.
1) If the parent is explicitly checked, leave the children as they are, and ask the user through tooling if they want to check each unchecked subtask, delete it, or move it up a level.
2) If all of the children are checked, the parent stays unchecked, but tooling should ask the user if the parent is complete, or if another subtask should be added.
3) If the parent has a closer due date than the children, don't do anything unless you feel like warning the user i.e. hold the subtasks to their due dates, and hold the parent task to its due date.
The issue about descriptions I see as a non-issue: dictate that descriptions marry to the task above them. It would be nicer to be freer with mixing descriptions and tasks, but you'd have to introduce more tokens.
One thing in the thread that I don't find necessary is marking partial completion.
I don't have any experience with Sublime, but this seems like a very basic tree.
When reading the subtasks, all you have to hold is the stack of the checkbox states and due dates of higher task levels for tooling to answer any of the above questions. A tool could seek backwards in order to check a parent if the children were checked, the user was warned, and the user said they wanted the parent checked. But if instead you really only wanted to read a line at a time, you could add a dummy item called "[ ] Complete parent task" at the end of the subtask list in order to keep an unchecked parent with checked children consistent.
The problem for me is that a tree is what I have trouble organizing. If it's just a linear list of things, I'm not sure how useful it could be for me other than by setting alarms that I could set directly. There is never a time when one of my tasks isn't to break down another task into simpler steps; all but the simplest tasks I have really have "break this down" that as the default first subtask.
So one workflow datapoint for useful with subtasks, useless without subtasks.
I'd suggest creating a new version of the spec that requires more advanced parsing and let people add spec version to the top or bottom of the file via a comment. (adding comments would be really useful too)
I just use a big text file where I keep all notes and todos (do use a [] as well), separate dates in a structured way with most recent date at top. Typically edit it in emacs. It just keeps getting bigger and bigger, but it’s nice to have a single text file that I can search.
I like it and have used a similar homegrown solution for years.
I’d love to switch to a better supported one, but please: work in progress is obviously […]
Not ... but the actual … character which takes the same horizontal space as X on monospaced fonts.
Maybe use it as a second option?
Nice work, thanks for sharing.
I’d love to switch to a better supported one, but please: work in progress is obviously […]
Not ... but the actual … character which takes the same horizontal space as X on monospaced fonts.
Maybe use it as a second option?
Nice work, thanks for sharing.
Thanks for your feedback. I think for the status characters there are a lot of imaginable variations and preferences. In the end, I thought that restricting the spec to a single character per status would help to confine the overall complexity of the file format, so it’s a bit of a tradeoff.
That character is not directly on keyboards, so it requires additional, OS-specific knowledge to type it.
I don’t know. That’s a very common character.
I use a mostly identical system, except instead of lines in a textfile, I use files in a folder, where the status is denoted by the extention.
If you also assign specific icons per extension, which you can do e.g in Total commander, you have a nice icon-coded todo list.
Using files instead of lines has several advantages. E.g. you can add notes in an item. Copy paste/link across projects etc. Search items vs in-text. Use dotfiles or ignore-patterns to hide/unhide items, associate certain tasks with specific apps (e.g. calendar) ... etc etc.
Have been using this for more than a decade, works great.
If you also assign specific icons per extension, which you can do e.g in Total commander, you have a nice icon-coded todo list.
Using files instead of lines has several advantages. E.g. you can add notes in an item. Copy paste/link across projects etc. Search items vs in-text. Use dotfiles or ignore-patterns to hide/unhide items, associate certain tasks with specific apps (e.g. calendar) ... etc etc.
Have been using this for more than a decade, works great.
More discussion just 5 months ago shared by the author
https://news.ycombinator.com/item?id=30879327
https://news.ycombinator.com/item?id=30879327
Reminds me a bit of the Sublime Plugin PlainTasks that I used 10 years ago, or so [1] [2]
[1] https://github.com/aziz/PlainTasks [2] https://www.linux-magazine.com/Online/Blogs/Productivity-Sau...
[1] https://github.com/aziz/PlainTasks [2] https://www.linux-magazine.com/Online/Blogs/Productivity-Sau...
I have been abusing a convoluted version of Markdown for this:
::ProjectA
---
@@@Things to do
* Things done
::ProjectB
---
@@@Another thing
Easy to search for things like:
"@@@" for the current TODO (and also show it in the menu bar with SwiftBar)
"::ProjectName" to look for projects
"* " to keep in a date-stamped file. I have kept such files since 2009.
gist that preserves formatting: https://gist.github.com/hboon/2684da05fe6c5d7afbcbaa4d847824...
::ProjectA
---
@@@Things to do
@@@Sub-tasks
* Things done
::ProjectB
---
@@@Another thing
Easy to search for things like:
"@@@" for the current TODO (and also show it in the menu bar with SwiftBar)
"::ProjectName" to look for projects
"* " to keep in a date-stamped file. I have kept such files since 2009.
gist that preserves formatting: https://gist.github.com/hboon/2684da05fe6c5d7afbcbaa4d847824...
Very cool. For those that want to blog their lists, https://lists.sh has been a lot of fun.
https://erock.lists.sh/knowledge-management-apps
https://erock.lists.sh/knowledge-management-apps
I like the simplicity of it. Sorry if I've missed it but are there already good tools built around this?
There currently are a bunch of editor plugins and one CLI tool. You find a collection of tools (all third-party) linked from the project website: https://xit.jotaen.net
I am just getting more and more convinced that any personal todo list is useless.
Most useless part is priorities on personal list. If something like utility invoice is to be paid - just do it.
If it is something like "read Anna Karenina" it is not getting any priority ever it is just something I would like to do in my life.
So stuff that really needs to be done I will deal with without any todo list I will just remember it or deal with it right away.
Stuff that does not need to be done will not get done - and that is perfectly fine.
Different thing is if it is company "todo" list and I need to keep customer requests, well JIRA does the job.
In the end don't listen to me because there are many much more successful people than me, I am simply happy with what I achieved so far, maybe I would achieve more with todo lists but somehow I fail to see how these would help me in living my life.
Most useless part is priorities on personal list. If something like utility invoice is to be paid - just do it.
If it is something like "read Anna Karenina" it is not getting any priority ever it is just something I would like to do in my life.
So stuff that really needs to be done I will deal with without any todo list I will just remember it or deal with it right away.
Stuff that does not need to be done will not get done - and that is perfectly fine.
Different thing is if it is company "todo" list and I need to keep customer requests, well JIRA does the job.
In the end don't listen to me because there are many much more successful people than me, I am simply happy with what I achieved so far, maybe I would achieve more with todo lists but somehow I fail to see how these would help me in living my life.
> So stuff that really needs to be done I will deal with without any todo list I will just remember it or deal with it right away.
Just remember. That's exactly the thing I (for example) am not capable of. I keep forgetting everything. Every time I have some spare time, I am checking my todo first if there's something I need/want/can do.
Just remember. That's exactly the thing I (for example) am not capable of. I keep forgetting everything. Every time I have some spare time, I am checking my todo first if there's something I need/want/can do.
Thanks for your point of view.
It is also why I am writing comments on the internet, to see what are other people life experiences.
It is also why I am writing comments on the internet, to see what are other people life experiences.
My experience is that physical to-do lists are great for sitting down, surveying what needs doing, and deciding what you’re going to do today. Including decisions like “I did not read any of Anna Karenina yesterday but I still want to do this so I am putting it on today’s list, and while I am thinking about this I took 5s to take it off the shelf and put it by the comfy reading chair”. And things like “laundry is gonna eat 2h of my day today but I need some clean clothes ffs”. And “I have six important work projects and only 3h of actual productive time between meetings, I am going to work on projects X and Z today unless someone comes and screams about the other projects”.
Digital to-do lists are where tasks go to die.
I just keep on coming back to a nice notebook, a nice pen, and my variant of the Pomodoro method.
Digital to-do lists are where tasks go to die.
I just keep on coming back to a nice notebook, a nice pen, and my variant of the Pomodoro method.
I used to do that too on paper, but at some point I ended up opening a text file in Emacs and do exactly what I would do on paper, just in Emacs. It's only a small chunk of text, so I don't use org-mode or anything like that.
But yeah, not accumulating stuff requires a conscious decision and the will to stick to it. The same goes for paper, though. I have a coworker that at some point had a stack of paper over 20 cm high.
But yeah, not accumulating stuff requires a conscious decision and the will to stick to it. The same goes for paper, though. I have a coworker that at some point had a stack of paper over 20 cm high.
> Digital to-do lists are where tasks go to die.
I also am becoming convinced of this.
The issue is that you can keep adding to them. And if you’re the digital hoarder type - hello, my friend Alex! - you can never delete the old crap. So now you have this utterly unachievable list of things that seemed like a good idea at the time. And which have lost context due to time, so now you barely even remember what you meant.
I introduced Alex to Things.app’s feature whereby you can mark a task as ‘Cancelled’. So it takes it off the list, but you’re not pretending that you did it. I hope that helps him.
Me, I use slips of paper and a pencil. On my desk the slips closest to me are those that I’m doing, or should do, now. When there’s too much paper, it’s obvious. Throwing away (by sticking it on the spike) a piece of paper feels good. It’s just a piece of paper.
I also am becoming convinced of this.
The issue is that you can keep adding to them. And if you’re the digital hoarder type - hello, my friend Alex! - you can never delete the old crap. So now you have this utterly unachievable list of things that seemed like a good idea at the time. And which have lost context due to time, so now you barely even remember what you meant.
I introduced Alex to Things.app’s feature whereby you can mark a task as ‘Cancelled’. So it takes it off the list, but you’re not pretending that you did it. I hope that helps him.
Me, I use slips of paper and a pencil. On my desk the slips closest to me are those that I’m doing, or should do, now. When there’s too much paper, it’s obvious. Throwing away (by sticking it on the spike) a piece of paper feels good. It’s just a piece of paper.
I don't even try to follow by-the-book GTD anymore, but a lot of its principles speak strongly to me. In particular, the regular review cycle is critical. It feels great to have a process in place that explicitly grants me permission to delete/cancel the things I don't want or need to do anymore. As a result, I know that my todo list has only things on it that I actually care about.
> So stuff that really needs to be done I will deal with without any todo list I will just remember it
Well you're lucky then, because I frequently have to remind people of important things they (still) have to do and seem to have forgotten. Having such a list is a way to avoid the stressful situation of being late with things you can't postpone or which you benefit greatly from doing sooner rather than later.
Well you're lucky then, because I frequently have to remind people of important things they (still) have to do and seem to have forgotten. Having such a list is a way to avoid the stressful situation of being late with things you can't postpone or which you benefit greatly from doing sooner rather than later.
For me it's useful to rid my mind from nagging thoughts. I might be working on something while suddenly thinking about something else to be done. If I'm not writing it, I'll lose focus.
Writing it in a Todo list calms my mind and let me get back to whatever it is later, without worrying I'll forget about it.
My mind wonders quite a bit, so this is very beneficial for me.
something to consider is that certain todo's require the right location or context, for example if I'm at the office and it occurs to me to pay the utility bill, that would go on a "home" todo list.
Additionally, some todo's have different timeframes than others. I try to think of things as short term/immediate, medium term/this week, and long term/nextweek-before I die.
I'll occasionally pick things of the long term list and cut them down into an action I could do immediate or this week, for example, get Anna karenina from the library.
Additionally, some todo's have different timeframes than others. I try to think of things as short term/immediate, medium term/this week, and long term/nextweek-before I die.
I'll occasionally pick things of the long term list and cut them down into an action I could do immediate or this week, for example, get Anna karenina from the library.
> So stuff that really needs to be done I will deal with without any todo list I will just remember it or deal with it right away.
hopefully obvious note that that simply isn't an option for anyone with ADHD.
hopefully obvious note that that simply isn't an option for anyone with ADHD.
My problem is that I'll never remember to do those things on my own. I have repeating items for things that seem obvious but that life experience has demonstrated that I just can't track on my own. I wish I could remember to order flowers for my wife in time for them to be delivered before our anniversary, but I won't. A todo app for me is a lifesaver: instead of being all stressed out that I'm forgetting something important, I can get all that stuff out of my head and concentrate on other things.
Isn't a repeating calendar event with an alert a better tool for this? But then you have to remember to check your calendar or to do the thing that alert you just snoozed/ignored was reminding you to do. Don't forget to check your todo list from time to time...
I have the same problem as you, of remembering things I need to do. But I've not found todo lists to actually help, in fact I find if I take too much time to maintain the list, I have less time to spend doing the things I'm supposed to do.
Kind of like remembering phone numbers. I don't know anyone's phone number anymore, because I don't have to, because I have a place that I can store them all. The difference is that the phone dials it for me when I tap it; my todo list doesn't carry out the tasks I write on it, but it does help me to forget them faster!
It's some mixture of https://xkcd.com/1906/, https://xkcd.com/927/ and https://xkcd.com/1319/
I have the same problem as you, of remembering things I need to do. But I've not found todo lists to actually help, in fact I find if I take too much time to maintain the list, I have less time to spend doing the things I'm supposed to do.
Kind of like remembering phone numbers. I don't know anyone's phone number anymore, because I don't have to, because I have a place that I can store them all. The difference is that the phone dials it for me when I tap it; my todo list doesn't carry out the tasks I write on it, but it does help me to forget them faster!
It's some mixture of https://xkcd.com/1906/, https://xkcd.com/927/ and https://xkcd.com/1319/
I find a TODO list useful for those things that need to be done today as well as others sometime in the next two weeks. For whatever reason, it can't be done today but it does need to happen. Putting a reminder on my calendar sometimes works for me and sometimes doesn't depending on what other supporting actions or information or whatever go along with it. If the calendar reminder pops up and I'm not "ready" to work on that it can get lost. On my TODO list, I see a constant reminder that the due date is coming and I can ensure that I find the time to complete it. I'm not always the best at looking well ahead on my calendar.
That's how my mind works, YMMV.
That's how my mind works, YMMV.
Some of those repeats are more flexible, like "water my plant 10 days after I last watered it". It's not going to fall over and die if I miss a day or 2. That also lets me treat my calendar as sacred: if I have an appointment there, I have to be at that place and time. My dentist won't amused if I'm a day late.
I hate recommending specific apps, but after using OmniFocus for years, I started using Things a few months ago and it's been heavenly. It's not as powerful as OF, but has all the features I actually need and not much else. I'm not tempted to waste time making my workflow absolutely perfect and optimal instead of just, you know, doing things.
I hate recommending specific apps, but after using OmniFocus for years, I started using Things a few months ago and it's been heavenly. It's not as powerful as OF, but has all the features I actually need and not much else. I'm not tempted to waste time making my workflow absolutely perfect and optimal instead of just, you know, doing things.
I have a completely different approach. My personal TODOs are of different type: they are necessary, non-immediate, with varying emotional load (pleasant-unpleasant). I manage them using a combination of calendar and at-based reminders. These include things like teeth cleaning, cancelling a subscription, calling my parents for their anniversary and so on. I simply wouldn't be able to remember all these things without reminders, there are just too many of them.
Normal human brain can’t remember that much. It also helps to write down everything that needs to get done first, so that you can prioritize between them.
Maybe I am just on the boring side of life and I don't really have that much to do.
My biggest problem earlier was that I thought I should have a todo list to achieve things in life. As it turns out it just does not matter, my connections, my starting point in life was much more defining to what I can achieve today than any form of organization of my self I would implement.
Of course unless I would be totally undisciplined and disorganized, but it turns out that I was disciplined and organized enough to reach good life and adding todo list is not something that would help me.
My biggest problem earlier was that I thought I should have a todo list to achieve things in life. As it turns out it just does not matter, my connections, my starting point in life was much more defining to what I can achieve today than any form of organization of my self I would implement.
Of course unless I would be totally undisciplined and disorganized, but it turns out that I was disciplined and organized enough to reach good life and adding todo list is not something that would help me.
[deleted](1)
I came up a personal solution to Kanban's in a text file years ago. It's pretty simple in concept and easy to type. Here it is:
- means not started.
* is in progress.
+ is complete.
I shifted from text-files for todo lists to using an adapted Bullet Journal 3 or 4 years back. Some times I neglect it for a few weeks at a time, but I've found it really useful on the times when I have used it extensively. In many ways, the todo section has similarities to Kanban.
But anyway, one convention I picked up from there is:
But anyway, one convention I picked up from there is:
- for a comment - something to remind yourself of the context or information to remember
. for a task you want to do
date . for a task that needs to be done on/by a certain date
/ for a task that is started
X for a completed task
> for a task that moved to a later page
I see Kanban, I upvote !
Thanks for moving the challenge forward.
May I share with you one of our articles that talks about it, hope it helps :)
https://zenkit.com/en/blog/kanban-explained-what-youve-alway...
This is great. I just wonder whether it could be a superset of Markdown.
Creator here. [x]it! was deliberately designed as a strict data format that stands on its own, as I think this makes it easier to create tooling and work with the data programmatically. However, I think use-cases and preferences are as different as the people who use them, so [x]it! doesn’t aim to be the one-size-fits-all approach.
For reference, there was also some discussion about this topic going on here https://github.com/jotaen/xit/discussions/10.
For reference, there was also some discussion about this topic going on here https://github.com/jotaen/xit/discussions/10.
Why pad priority with dots? Why pad priority at all? The date format will allow bad clients to do the American yyyy-dd-mm thing, using a standard would make it unambiguous.
> Why pad priority with dots? Why pad priority at all?
It's optional, so I'd assume it's for people who want to start the sentence from same aligned column.
> The date format will allow bad clients to do the American yyyy-dd-mm thing, using a standard would make it unambiguous.
Isn't 2022-08-23 the standard format; ISO 8601?
It's optional, so I'd assume it's for people who want to start the sentence from same aligned column.
> The date format will allow bad clients to do the American yyyy-dd-mm thing, using a standard would make it unambiguous.
Isn't 2022-08-23 the standard format; ISO 8601?
> It's optional, so I'd assume it's for people who want to start the sentence from same aligned column.
Yes, visual alignment is the first purpose; the other is if you want to sort your lines lexically (as described elsewhere in this discussion), then the dots enable deterministic ordering, because exclamation marks sort before dots.
> The date format will allow bad clients to do the American yyyy-dd-mm thing, using a standard would make it unambiguous.
The format for dates is a subset of ISO-8601, except for the slashed variant (2020/12/31) that’s there for convenience, and the notation for quarters (2022-Q1).
Yes, visual alignment is the first purpose; the other is if you want to sort your lines lexically (as described elsewhere in this discussion), then the dots enable deterministic ordering, because exclamation marks sort before dots.
> The date format will allow bad clients to do the American yyyy-dd-mm thing, using a standard would make it unambiguous.
The format for dates is a subset of ISO-8601, except for the slashed variant (2020/12/31) that’s there for convenience, and the notation for quarters (2022-Q1).
In my experience, your titles need to be more visually distinct for when lists get long
`====== MORNING ERRANDS ======`
Is it good at indented text wrapping?
`====== MORNING ERRANDS ======`
Is it good at indented text wrapping?
You’d be free to format your titles like that, if you prefer. The only restriction for titles is that the line cannot start with whitespace or `[`.
Not sure what you mean by the text wrapping bit, but I think that appropriate/pleasant text wrapping would be a concern of an editor.
Not sure what you mean by the text wrapping bit, but I think that appropriate/pleasant text wrapping would be a concern of an editor.
I’ll give this a shot since he went through the trouble of creating a vscode extension for it.
Nice. Supports emoji's? Looks like the UTF-8 is not yet supported directly.
[x]it! files are UTF-8 encoded by default. The predefined syntactical elements (such as checkboxes, priorities, or due dates) are composed from ASCII characters, but outside of that (e.g. in item descriptions) you can use all available Unicode characters without restriction.
This is very cool. Only if i could pin my todolist on desktop.
This should be integrated into Markwhen.com
I can only recommend NotePlan instead
> Letter: a character from the Unicode Letter category (L)
This definition is insufficient for many scripts, such as Indic scripts. My name “Chris” is written in Telugu as “క్రిస్”: letter ka, sign virama (which suppresses the inherent vowel, and also joins the next letter and vowel sign as a conjunct in this instance, as part of the same syllable—if you didn’t want that, you’d insert a ZERO-WIDTH NON-JOINER and get క్ రి [minus the space, HN turned by ZWNJ into a space :/] instead of క్రి), letter ra, vowel sign i, letter sa, sign virama (which this time just suppresses the inherent vowel). Six code points, of which three are Other_Letter (part of Letter) and three Nonspacing_Mark (part of Mark, not Letter).
Unicode’s Letter general category is almost never what you want. To begin with, you should instead use the “Alphabetic” property, which examination of https://www.unicode.org/reports/tr44/#Alphabetic and https://www.unicode.org/reports/tr44/#GC_Values_Table shows to be a superset of Letter, adding the Letter_Number (Nl) general category and the Other_Lowercase, Other_Uppercase and Other_Alphabetic properties.
But actually, even Alphabetic isn’t quite the right tool: some scripts don’t separate words with non-alphabetical characters, and some scripts use non-alphabetical characters in the middle of words (e.g. ZWJ and ZWNJ in Indic texts, or apostrophes in English). For most correct results, I believe you actually need to get into full text segmentation to find word breaks, as defined in UAX #29 <https://www.unicode.org/reports/tr29/>.
As usual: language is fiendishly complicated.
The other definitions are a strange mixture. Digit is ASCII-only, which makes sense for due date, but is inconsistent with Unicode letters elsewhere.
> The tag name MUST only contain letters, digits, or the characters _ or -. It MUST be treated as case-insensitive.
This is somewhat poorly defined, and I’m confident that from such a definition you’ll get multiple incompatible implementations. I would say that you probably want to specify something based on Unicode’s caseless matching; see https://www.unicode.org/versions/Unicode14.0.0/ch05.pdf#G217... which will give you much to read and despair of ever understanding. (The whole two and a bit pages of that subsection are worth reading. And I wouldn’t complain if you decided it was worth reading a lot more of the Unicode spec.)
But in this place, I don’t think you actually want letters/digits/_/- anyway. I think that for tag names you’d do better with using UAX #31 <https://www.unicode.org/reports/tr31/> identifiers of some form. Note its optional medial characters (how you’d add -), its “hashtag identifiers”, and its remarks on case folding.
This definition is insufficient for many scripts, such as Indic scripts. My name “Chris” is written in Telugu as “క్రిస్”: letter ka, sign virama (which suppresses the inherent vowel, and also joins the next letter and vowel sign as a conjunct in this instance, as part of the same syllable—if you didn’t want that, you’d insert a ZERO-WIDTH NON-JOINER and get క్ రి [minus the space, HN turned by ZWNJ into a space :/] instead of క్రి), letter ra, vowel sign i, letter sa, sign virama (which this time just suppresses the inherent vowel). Six code points, of which three are Other_Letter (part of Letter) and three Nonspacing_Mark (part of Mark, not Letter).
Unicode’s Letter general category is almost never what you want. To begin with, you should instead use the “Alphabetic” property, which examination of https://www.unicode.org/reports/tr44/#Alphabetic and https://www.unicode.org/reports/tr44/#GC_Values_Table shows to be a superset of Letter, adding the Letter_Number (Nl) general category and the Other_Lowercase, Other_Uppercase and Other_Alphabetic properties.
But actually, even Alphabetic isn’t quite the right tool: some scripts don’t separate words with non-alphabetical characters, and some scripts use non-alphabetical characters in the middle of words (e.g. ZWJ and ZWNJ in Indic texts, or apostrophes in English). For most correct results, I believe you actually need to get into full text segmentation to find word breaks, as defined in UAX #29 <https://www.unicode.org/reports/tr29/>.
As usual: language is fiendishly complicated.
The other definitions are a strange mixture. Digit is ASCII-only, which makes sense for due date, but is inconsistent with Unicode letters elsewhere.
> The tag name MUST only contain letters, digits, or the characters _ or -. It MUST be treated as case-insensitive.
This is somewhat poorly defined, and I’m confident that from such a definition you’ll get multiple incompatible implementations. I would say that you probably want to specify something based on Unicode’s caseless matching; see https://www.unicode.org/versions/Unicode14.0.0/ch05.pdf#G217... which will give you much to read and despair of ever understanding. (The whole two and a bit pages of that subsection are worth reading. And I wouldn’t complain if you decided it was worth reading a lot more of the Unicode spec.)
But in this place, I don’t think you actually want letters/digits/_/- anyway. I think that for tag names you’d do better with using UAX #31 <https://www.unicode.org/reports/tr31/> identifiers of some form. Note its optional medial characters (how you’d add -), its “hashtag identifiers”, and its remarks on case folding.
Thanks for your detailed notes, I’ll look through your links.
Just to clarify for context, the “letter” definition is only relevant for tags, so outside of #tags (in item descriptions, or group titles) you can use any Unicode character you want.
Just to clarify for context, the “letter” definition is only relevant for tags, so outside of #tags (in item descriptions, or group titles) you can use any Unicode character you want.
Obligatory xkcd: https://xkcd.com/927/
Seriously though, this looks great.
Seriously though, this looks great.
I also tend to code year/month after the symbol like 2022/08 (not shown in the listed examples)
By keeping a single char in the first line, I can easily grep and sort tasks to make sense of things. I know it's very crude, but it works well for my purposes. I welcome any suggestions or improvements
(edit: formatting)