Why I still write on paper
There’s something that happens when I pick up a pen that doesn’t happen when I open a new buffer. The thinking is different — less filtered, less structured, more honest. Ideas that would never survive the friction of forming a heading and choosing a tag actually get written down. First drafts of decisions, rough task lists, things I’m trying to work out, all of it lands on paper before it’s ready to be digital.
I’ve tried replacing this with digital tools. Org-capture is excellent for structured input, but for capturing a fleeting thought mid-meeting or sketching out a problem while commuting, I still reach for paper. The reMarkable is my compromise: it’s close enough to writing on paper that it doesn’t disrupt the thinking, and close enough to a computer that the notes don’t stay trapped on dead wood.
The problem is that notes on a reMarkable and notes in Org-mode don’t naturally talk to each other. This post is about the pipeline I built to close that gap.
The two tools and why they complement each other
The reMarkable is good at one thing: letting you write without getting in the way. The e-ink display doesn’t glow, doesn’t notify you, doesn’t tempt you to check anything. The battery lasts days. The pen latency is low enough to feel like paper. Cloud sync happens automatically in the background — you don’t think about it. For first-pass capture of any kind of thinking, it’s hard to beat.
Org-mode is good at different things. It’s plain text, version-controllable, programmable. It integrates with agenda, GTD-style workflows, time tracking, archiving. When information is in an .org file, the full Emacs ecosystem is available — you can schedule it, tag it, refile it, clock time on it, link it to other notes. For organizing and acting on information, it’s where I want everything to end up.
The gap is obvious. reMarkable is where I write things down. Org-mode is where things become actionable. Without a bridge, I was manually transcribing notes — which defeats most of the point of capturing on the device in the first place.
How the sync pipeline works
The pipeline has three stages: download, recognize, and structure.
Download is handled by rmapi, a command-line client for the reMarkable cloud API. It downloads notebooks as .rmdoc files — the native reMarkable format, which is essentially a zip archive containing per-page binary stroke data and metadata. I run this for each notebook I want to sync.
Recognition is where handwriting becomes text. I use the MyScript Cloud API, which accepts raw reMarkable page data and returns recognized text. The API is HMAC-authenticated, accepts batched requests, and handles Latin-script handwriting well enough for practical use. The free tier covers 2000 pages per month, which is more than I need.
One piece of engineering worth calling out: hash-based deduplication. Before sending a page to the API, the script computes a hash of the page content and compares it against a local cache. If the page hasn’t changed since the last run, it’s skipped. This matters in practice — a 20-page notebook where you’ve written 2 new pages today sends 2 pages to the API, not 20. Quota is preserved, and the run takes seconds.
Structuring is handled by a Python script that takes the raw recognized text from MyScript and organizes it into Org format. Each notebook becomes an .org file; pages become headings or entries under headings, depending on how the notebook is organized. The results land in emacs-org/remarkable/, organized by notebook name. A notebook called “Projects” on the device becomes emacs-org/remarkable/Projects.org on disk.
The whole thing runs nightly via cron at 02:00. By the time I open Emacs in the morning, yesterday’s handwritten notes are already there.
Notebook structure on the device
I keep three notebooks on the reMarkable that feed into this pipeline: Projects, Areas, and Quick Sheets.
Projects holds working notes tied to specific projects — meeting notes, rough plans, things I’m working through. Areas holds reference material and ongoing concerns that don’t have a deadline. Quick Sheets is the capture inbox: whatever I write when I don’t want to think about where it belongs yet. Random ideas, to-do items, things to look up, fragments of thought.
After nightly sync, Quick Sheets becomes the Org file I triage first. Something like “Call Jan re: contract renewal — deadline Friday” appears as a plain text entry. Turning it into a scheduled TODO in Emacs takes ten seconds. The capture happened on paper; the action lives in the agenda.
What works well
HWR accuracy for clean, reasonably paced handwriting is high enough to be useful without heavy editing. Not perfect — there are occasional word-level errors — but close enough that the recognized text is readable and the context is always restorable even when individual words are off.
The automation itself is reliable. Once the cron job is set up, I don’t think about it. Notes appear. The hash deduplication means I can re-run the script manually without worrying about duplicates accumulating.
The Org integration is the payoff. Once notes are in .org files, everything Emacs offers is available. Tags, scheduling, refiling into project files, linking to related notes — none of that required any special work on the reMarkable side. The device just needed to get the text into a file.
Limitations and honest trade-offs
The Czech diacritics problem is real. Fast or slightly sloppy handwriting, especially with Czech-specific characters like ě, š, č, ř, produces more recognition errors than clean Latin script. “Přečíst knihu o Kafkovi” might come out as “Precist knihu o Kafkovi”. Readable and context-restorable, but not clean. For notes that matter, a proofread pass is necessary.
Symbols don’t transfer. Diagrams, arrows, flowcharts, mathematical notation — anything that isn’t text is either garbled or empty in the output. A page with a hand-drawn architecture diagram produces only the text labels, if anything. This is a known constraint of the HWR approach, not a bug in the implementation.
The pipeline is one-directional and always will be. reMarkable is a capture device. You write on it; the notes flow to Org. Nothing flows back. This is fine for my workflow, but worth stating clearly.
There are two external dependencies worth noting. rmapi requires reMarkable cloud credentials — if you don’t want to use the cloud, this pipeline doesn’t work as described. MyScript is a third-party API that requires registration and could change pricing or availability. The free tier has been stable, but it’s not self-hosted.
Sync is nightly, not real-time. If I write something at 10pm and need it in Emacs immediately, I run the script by hand. But the default cadence is once a night, and for most of what I write, that’s enough.
How to replicate this
The setup requires some comfort with Python, command-line tools, and cron. It’s not complex, but it’s also not a one-click install.
Tools you need:
- rmapi — CLI for reMarkable cloud. Handles authentication and
.rmdocdownload. (GitHub: juruen/rmapi) - MyScript Cloud API — Handwriting recognition. Register at developer.myscript.com for a free API key. The batch endpoint accepts reMarkable page data directly.
- Python 3 — For the post-processing script that structures recognized text into Org format. Standard library is sufficient; no exotic dependencies.
- cron — For nightly scheduling.
The rough flow: configure rmapi with your reMarkable credentials, register for a MyScript API key, wire up the Python script to call both, point it at your Org directory, and schedule it. The deduplication cache is a simple JSON file mapping page hashes to recognized text — straightforward to implement.
I’m not publishing the script as a ready-made package because it’s too tied to my specific notebook structure and Org conventions. But the components are all documented, the API is straightforward, and the overall architecture is simple enough to re-implement in an afternoon.
The result: I write on paper and my agenda knows about it by morning. Not magic — just a cron job and a working API key.