I disagree, having the spec is the first step to building tooling around it. People can port plugins that support this format to vim, eMacs, VSC, etc.. and create functionality around it. For example: reorder into a date view
> Software engineering should be about more productive UX, not flexing one’s ability to parse arbitrary syntactic art.
Tasks lists are generally useless without their context. It makes sense to have tasks along their context (be it plain-text, markdown, JS, python...) Also it's more maintainable and portable. YAML/JSON/SQlite will be a headache when the user decide to migrate to another tool. This approach only require a text editor, any text editor in any platform. You can plug in whatever you prefer for syncing and sugar.
For a very few cases I use YAML to store data that isn't parsed by any program (only by me). And I can write a comment like 'TODO: Do something.' or "FIXME: X isn't working.' On the terminal using a code searcher and a text editor I can easily find and jump on those.
UX creates context from the users perspective, not the back end data format. This format creates a headache in that nothing can parse or write it except the humans that learn it.
I can easily search an SQLITE file from a CLI (wrote me a tool a long time ago to fuzzy find). I doubt the YAML lib for Python is going to become obsolete soon. I can instantly work with that format on any machine with a common language. There’s already Taskwarrior.
It’s electrons in a machine, hundreds of different paths to porting it around, changing it, etc.
Look, don’t get me wrong; I’m not about to pour sugar down someone’s gas tank. I’m just walking through my inner monologue debating this format someone chose to put up for open review and discussion.
I write data that makes sense to have as normalized in YAML format even if I'm not parsing it in any program because I may do so in the future and YAML is ergonomic.
But for things that shouldn't be normalized I write then as plain-text notes using markdown notation. It isn't true that nothing can parse plain text. I wrote a tool to do that and it works as expected. Of course it's bad design if you look exclusively from the software engineering perspective but ergonomics also matter and parsing text isn't hard.
Don't get me wrong also. I'm just a guy with peculiar use cases and bad experiences migrating away from Evernote and later Joplin.
I think the viewpoints on that are wildly diverse. As far as I’m concerned, it’s the exact opposite. Hence, I think it’s great that there is a big variety of different approaches that everyone can pick from according to their own preferences.
Sure; I’m just expressing mine. The “glyphs and how to display or sort them wars” aren’t important enough to me to take real offense to alternatives. This is just idle discourse for me.
Lindy Effect type thoughts, why import another dependency; familiarity, existing portability, and habits with current formats; deep and wide tooling and language support… road built; let’s drive to shovel poetic drivel out the door.
I think the author is saying there is already a spec, just one abstraction layer above: Plain text. Anything that can read and write text can interact with the to-do list.
