Introducing Beryl: a Markdown Todo List

Posted on Jan 6, 2023

tl;dr: I want to make Obsidian, but for todo lists. It’s a spiritual successor to todo.txt

I lean pretty hard on todo lists. I’ve been a heavy Todoist user for about 7 years. In that time I’ve changed pretty much every other software I use, except for Todoist. I really like its simplicity, and the ability to ‘blind enter’ a task with only the keyboard.

But Todoist, at the end of the day, is a proprietary project. It’s moving away from being text focused. And I don’t own my data.

Last year I moved from Notion to Obsidian. It has been awesome for lots of reasons. One big one is I actually have my notes on my actual hard drive.

I want to do that for my todo list.

I like the idea of using gemstone names for projects, so for the time being this project is Codename Beryl.

Eventual target features:

  • All data is stored in text files
  • markdown support everywhere
  • normal todo list features
    • projects
    • priority
    • due dates
    • context tags
    • subtasks
    • comments on tasks
  • lightning fast sync between devices

I landed on this feature list based on my own usage, and poking around the todo.txt issues to see what people are complaining about

I absolutely love the idea of todo.txt, its simple and straightforward in a way I really really like. Unfortunately, the lack of subtasks is a really big deal for me, so I really can’t use it.

How do we design a spiritual successor to todo.txt?

For the uninitiated, todo.txt tasks go into one single file (todo.txt, surprise surprise). Tasks look like this:

x (A) 2022-09-20 2023-03-29 task titie +projectName @context due:2022-12-19 any:tag

This is my current thought for how a markdown based todo list would work:

- [ ] task title priority:1 context:contextName start:date finish:date due:date
	- [ ] subtasks with one more tab
- [ ] task title p:1 c:context s:date f:date d:date
	- [ ] subtasks
		**markdown** comments with one more tab
		must be right after task
		- [ ] subtasks start right after comments

I think just using tags for everything allows for a lot more flexibility. For example, some people ight want to differentiate between the typical GTD ‘context’ and physical location. I think it makes a bit more sense and this is my thing dag nabit!

The general order of how I want to implement this

  1. go parser
  2. golang bubbletea tui
  3. wails desktop app
  4. capacitor mobile apps

I’m very excited to play around with charm and wails, they both seem really cool! It seems like I can stay within the go ecosystem for most of what I want to do with this project.

I don’t think I’ve ever been this genuinely excited about a potential project. I’m pretty into task systems in general, so implementing my own sounds very fun!