Todo Txt

When my to-do list started bleeding across sticky notes, calendar reminders, and the notes app, I switched to the plain-text 'todo.txt' approach and never looked back. I love that it's just a single .txt file with simple conventions: priorities like (A), projects with +project, contexts with @context, and optional key:value metadata. Depending on whether I'm on my phone, laptop, or a tiny Linux droplet, I reach for different tools — here are the ones I actually use and why they stick.

On Android I live in 'Simpletask' (there are a couple of forks; pick the actively maintained one). It syncs via Dropbox or folder sync, shows clear filters for priority, project, and context, and gives you a quick way to tap through priorities without typing parentheses. For iPhone, 'Todo.txt Touch' has a clean interface and the same conventions, so your file stays portable. On Windows, I use 'todotxt.net' (or QTodoTxt if I'm on Linux) for a lightweight GUI that can sort by priority, filter by +project, and bulk edit tags. If I'm messing with automation or want the fastest possible workflow, the original CLI tool 'todo.sh' is unbeatable — you can write tiny scripts to bump priorities, auto-add dates, or produce custom reports.

For editing in the context of writing or coding, I sometimes drop the file into VS Code or Sublime Text with simple syntax highlighting or the PlainTasks plugin; that makes batch edits and regex searches painless when I'm pruning an overdone project list. A few practical tips I picked up: keep a consistent metadata key like due:YYYY-MM-DD so filters work predictably; don't bury priorities in the middle of lines — put (A) at the very front; and set up automatic sync (Dropbox, Nextcloud, or Git) so your mobile and desktop views always match. If you want somelike super minimal: a plain text editor plus smart search is enough, but using these apps makes handling tags and priorities feel deliberate rather than chaotic. Personally, mixing a friendly mobile app for quick taps with a CLI or desktop tool for heavy organizing has been the sweet spot for me — fast inputs on the go, powerful edits at the desk, and the reassuring simplicity of a single text file that I can grep or commit anytime.

If you want suggestions tailored to your platform or a short setup walkthrough (sync, basic filters, and a couple of handy scripts), tell me what devices you use and I’ll sketch out a step-by-step that matches your habits.

Okay, let’s nerd out about this — syncing a plain old 'todo.txt' across Android, iPhone, and desktop is wonderfully simple once you pick the right sync layer and apps, but there are a few little gotchas I’ve learned the hard way.

First, pick your sync service. For most folks Dropbox is the path of least resistance because many dedicated todo.txt apps speak Dropbox natively. If you care more about privacy or run your own server, Nextcloud/WebDAV is stellar. Syncthing is great for direct device-to-device sync (no cloud), but iOS support is fiddly compared to Android and desktop. Once you pick a provider, create one canonical file like ~/Dropbox/todo/todo.txt (or the equivalent folder in iCloud Drive / Nextcloud) so every client points to the same path.

Next, choose the apps. On Android I use 'Simpletask' (or the Simpletask family) because it understands the todo.txt format, supports Dropbox/WebDAV, and has filtering/undo. On iPhone there’s 'Todo.txt Touch' or any plain text editor that can open files via the Files provider — many iOS apps can edit files inside Dropbox or iCloud Drive. On desktop I alternate between a small GUI (like 'todotxt.net' on Windows or a light editor on macOS) and the command-line tool 'todo.sh' / 'todotxt-cli' when I want power. Point every app to the same file path in your chosen sync service and let the cloud do the heavy lifting.

A couple of practical tips from my own messy inbox: always let the sync finish before switching devices to avoid conflicts, and check app settings for atomic saves (some editors rewrite the whole file and can create duplicates). If you expect heavy concurrent editing, consider using Git on top of the file for history and easier conflict resolution, or use Nextcloud’s versioning. Name conventions help: keep one file (not multiple files named todo1.txt/todo2.txt) and use lower-case dot extension like todo.txt. Finally, add automated backups (a daily cron or cloud versioning) and consider small automations — I pipe urgent @today items into my calendar or set phone reminders via shortcuts/Tasker. Once it’s set up, that single plain-text brain is surprisingly calming — like a tidy bookshelf for your tasks.

Yes—you can definitely hook 'todo.txt' into IFTTT, but it usually needs a little glue. I’ve toyed with this for a while and found there are three practical approaches depending on how hands-on you want to be.

The simplest no-code route is to keep your 'todo.txt' in a cloud folder that IFTTT can watch, like Dropbox or Google Drive. Create an applet that triggers on "New file in folder" or "File updated" and then pair that with whatever action you want (push notification, calendar event, smart light blink). The caveat is that IFTTT won’t parse your tasks for you — it just sees the file change. So if you need triggers based on things like a priority '(A)', a context '@home', or a 'due:' tag, you’ll need something to read and parse the file first.

That’s where a tiny script or mobile automation comes in. I run a small Python watcher on my laptop that syncs with the Dropbox copy of my 'todo.txt', looks for new lines matching patterns I care about, and sends a POST to IFTTT Webhooks (https://maker.ifttt.com/trigger/{event}/with/key/{key}) with the task details. From there IFTTT can light up my Philips Hue, log to a spreadsheet, or send me a text. If you prefer no scripting, try combining IFTTT with Zapier or Make.com which can read files and do basic parsing — that’s a nice middle ground between full code and pure cloud triggers.

Okay — if I'm treating a plain todo.txt like a tiny vault, I usually pick one of two comfortable paths: file-level encryption with a well-vetted tool, or a locked vault/container that feels like a folder you can carry around. For a single file, symmetric GPG is simple and robust: I run something like gpg -o todo.txt.gpg -c todo.txt to create an AES-encrypted blob and then gpg -d todo.txt.gpg > todo.txt when I need to edit. It’s fast, widely supported, and integrates nicely with editors via vim-gnupg or Emacs’ EasyPG so I can open, edit, and save without wresting with temporary files.

If I want multi-file convenience and encrypted filenames (so the names of files don’t leak sensitive hints), I lean toward a fused solution: 'gocryptfs' or 'cryptomator' give me an encrypted mount that I can treat like a normal folder. I mount the vault, edit my todo.txt with any app, then unmount and I’m back to a safe encrypted chunk. For cross-device sync, 'cryptomator' has mobile apps and desktop clients, so it plays nicely with cloud providers without exposing plaintext.

Some practical tips I always follow: pick a strong passphrase (use a password manager to generate + store it), back up the encrypted file/container and the key material in at least two places, and be careful with temporary files — many editors create .swp/.tmp files that can leak content unless the editor uses secure deletion or a memory-only buffer. If you want more automation, scripts that decrypt-to-temp, launch editor, then re-encrypt on close are super handy. Personally, I mix GPG for quick notes and a small cryptomator vault for daily todo management — both give me peace of mind and portability.

Oh, absolutely — you can do that, and it's not as scary as it sounds once you break it into steps. I've wrestled with converting a messy Evernote dump into a tidy 'todo.txt' list more than once, and there are three practical routes I usually suggest: export-and-script, export-then-manual-clean, or use a third-party bridge/service.

If you want a reliable, repeatable approach I go with export-and-script. From 'Evernote' export your notes as an .enex file (that XML-based export saves titles, content in ENML, tags, created/updated timestamps). Inside the ENML, checkboxes appear as elements — those are your actual tasks if you used checkboxes. I typically write a small script (Python is my go-to) that parses the .enex, extracts each note's title, created date, tags, and then walks the HTML to find each and the surrounding text. Map tags to +project or @context in 'todo.txt' lines, use the created/updated date as the task date if you like, and output lines like: "(A) 2025-09-06 Do laundry +Home @Chores" or just "2025-09-06 Do laundry" for simplicity. If you prefer, convert the .enex to Markdown first with an existing converter and then grep for lines starting with - [ ] or similar.

There are a few gotchas I always warn people about: checkbox markup can be inline or separated by paragraphs, attachments (images, PDFs) won't convert to plain text tasks, and you have to decide how to treat incomplete tasks vs completed ones (todo.txt uses a leading 'x' to mark completion). Test on a small export before mass-converting, and keep a backup. If scripting isn't your vibe, there are no-code services like Zapier or IFTTT that can pipe new notes into Todoist or a Google Sheet which you can then export to todo.txt format, but that’s more for ongoing sync than bulk migration. Personally, I like the control of a simple script — it’s faster once set up and you can tailor project/context mapping — but either way, it’s totally doable and kinda satisfying to watch your scattered notes become a streamlined todo list.

Honestly, my favorite workflow for recurring tasks in todo.txt is the one that mixes a bit of automation with a tiny bit of ritual — it keeps things reliable without turning my life into a robot.

I usually keep recurring tasks marked with an explicit tag like rec:daily or rec:monthly and always attach a due:YYYY-MM-DD. For example: (A) Pay rent +Home due:2025-09-01 rec:monthly. I use the 'todo.sh' script because it understands rec: out of the box: when I mark a recurring task done, the CLI can automatically create the next instance with the new due date. That saves me from manually re-adding stuff. For tasks I want hidden until they’re relevant (like a subscription renewal far in the future) I use wait:YYYY-MM-DD so my everyday list stays clean.

For anything more bespoke I run a small helper script (a 50-line bash or Python script) on completion or as a daily cron job: it scans for completed items with rec:, calculates the next due date using dateutil or GNU date, and appends a new todo line. I keep my todos in a git repo and sync via Dropbox/Nextcloud so I don’t lose history. Finally, I build a couple of aliases: one to list only overdue recurring items, one to nuke stale ones, and a weekly habit check with a filter like grep rec: | grep -v done, which helps me catch quirks. It’s simple, resilient, and still feels human-sized.

When my todo.txt list starts to look like a chaotic comic crossover, I switch into director mode and give every project a clear stage and cast. I like to treat each project as a short story: one headline milestone, a handful of actionable scenes (tasks), and a place to stash notes. In practice that means using consistent project tokens (+ProjectName), context tags (@home, @office, @phone), and metadata like due:YYYY-MM-DD and created:YYYY-MM-DD. I usually pick short, lower-case project names (for example +website-redesign or +taxes2025) so filters stay tidy and predictable.

For structure, I often create a top-level task that represents the project itself and then list subtasks that reference the same +Project tag. For example:
(A) 2025-09-01 Plan content outline +website-redesign due:2025-09-07 created:2025-08-28
(B) 2025-09-02 Draft homepage copy +website-redesign @computer t:2h
(C) 2025-09-05 Review with designer +website-redesign @meetings
This way I can grep for +website-redesign and see the whole arc. If I want visible milestones I add a headline like "Start: Rebuild homepage +website-redesign" and mark it complete when the phase is done. For nested or complex projects I adopt a simple numbering scheme in task text like "1/5: Wireframe header", "2/5: Select images" — it’s low-tech but gives a sense of progress without needing fancy features.

The other things that save my sanity: keep one or two contexts for each task (avoid spamming tags), use due: only for real deadlines, and add t: for time estimates so I can batch short tasks. I also use a 'blocked' keyword for tasks waiting on someone else (or depends:TaskID if my tool supports IDs). Tools like the todo.txt CLI, Simpletask, or any editor + grep make it easy to filter by +project or @context. Finally, archive completed items regularly — I keep a monthly archive file — and periodically rename project tags for consistency. It’s surprisingly satisfying to close the final milestone and watch the +project disappear from the active list; it feels like finishing a season of a good series, and I end the session with a little grin and a fresh cup of coffee.

I've fought with this exact problem before and it feels like trying to shove a square peg into a round hole — Google Tasks simply doesn't have a native 'tags' field like todo.txt expects. That said, I found a few practical, low-friction ways to move your items across without losing the meaning of your +projects and @contexts. The core idea I use is: decide how you want to query tasks later (by project, by context, or both), then encode tags in a place Google Tasks will keep and let you search — typically the task notes or the title — and optionally map projects to separate task lists so you get an extra organizational layer.

Practically, I recommend this workflow: back up your todo.txt, then run a small script that parses each line for the usual todo.txt parts (completion mark, priority like (A), dates, +project tags, @context tags, and extras such as due:YYYY-MM-DD). For each parsed line I create a Google Tasks task where the title is the human-friendly part (stripped of + and @ tags if you prefer), and the notes field contains a single canonical line that preserves everything: original raw line, plus a short metadata snippet like 'projects:+proj1,+proj2 contexts:@home,@errands'. If you prefer project-level separation, create one Google Tasks list per +project and insert the task into all relevant lists (or the primary project list and then duplicate or tag contexts in notes). Example mapping choices: project -> task list (good for inbox-style view by project); project -> prefix in title or notes (good if you want one combined list and fast search); contexts -> notes or title prefix (searchable in Google Tasks UI and through Gmail sidebar).

If you want a hands-on script, I used Python with the google-api-python-client. The parsing is straightforward regex or tiny parser: extract tokens starting with '+' or '@', pick up due:YYYY-MM-DD keys, then build a tasks.insert() payload with 'title', 'notes' and 'due' fields. Test on a handful of lines first. Also watch recurring tasks and advanced todo.txt extensions — Google Tasks has limited recurrence support, so I usually add a note like 'rrule:...' and adjust manually later. The small effort to keep the original raw line in notes saved me countless times when I needed to recover context or re-import differently. If you want, I can sketch a minimal script template or a checklist to run this safely on your file — it made the migration feel manageable for me, and I sleep better knowing nothing important got lost.

Okay, here's the lowdown from my painfully curious, tinkering brain: the most common reason your todo.txt lines aren’t translating their due dates into Taskwarrior is that Taskwarrior doesn’t natively speak the todo.txt format. If you just run something like 'task import todo.txt', Taskwarrior expects its own JSON export format, not plain todo.txt key:value pairs. That means either you need a converter that turns todo.txt into Taskwarrior JSON or you need to feed Taskwarrior explicit 'task add' commands that include a properly formatted due attribute.

When I debug this kind of thing I split the problem into two small checks. First, confirm the raw string in todo.txt: a valid todo.txt due token looks like due:YYYY-MM-DD (e.g., due:2025-09-07). If your file uses slashes (09/07/2025), a different ordering (DD-MM-YYYY), or natural words like due:tomorrow, the importer may not understand it. Second, test Taskwarrior itself by hand: run a single manual command such as task add Buy milk due:2025-09-07 and then list tasks. If Taskwarrior accepts that, the issue is the conversion step. If it rejects it, examine Taskwarrior’s date parsing — it prefers ISO-style dates or full ISO timestamps (YYYY-MM-DD or YYYY-MM-DDTHH:MM:SSZ).

Other little gremlins I’ve hit: Windows line endings or a BOM can confuse parsers, stray whitespace or punctuation after the date token (like due:2025-09-07,) can break detection, and some older converter scripts only look for lowercase tokens or exact spacing. My practical workflow is to run a small conversion script (there are community 'todo.txt to Taskwarrior' scripts on GitHub) or write a short Python loop that reads each todo line, extracts the due: token, normalizes to YYYY-MM-DD, and either calls 'task add' or emits Taskwarrior JSON for 'task import'. Try debugging with a single task first, and if you want I can sketch a tiny conversion snippet to run locally — I love these little automation puzzles and it usually takes one edited regex to get everything flowing smoothly.