Heynote: A Block-Based Scratchpad Built on CodeMirror and Electron

The scratchpad problem Heynote targets

Most text editors are built around files. You open one, edit it, save it, and close it. That model breaks down for the text that has no filename: a Slack message you are drafting and do not want to send by accident, a JSON response pasted out of a terminal, meeting notes, a daily to-do list. The README lists exactly these cases. The usual workarounds are an unsaved editor tab that you eventually lose, a notes app that fights you on formatting, or a file on disk you never name properly.

Heynote's answer is a large persistent text buffer that exists independently of any file you chose to open. Persistence is the first listed feature, and it is the one that matters most. The buffer survives restarts without a save step. The target user is described in the README as developers and power users, which is a fair description of the design: the feature list is dominated by syntax highlighting for roughly thirty languages, auto-formatting, multi-cursor editing and Emacs-like or custom key bindings. Someone who wants a WYSIWYG journal will find this app oriented away from them.

Blocks: the one structural idea in the buffer

Heynote does not give you one document with one language mode. It divides the buffer into blocks, and each block carries its own Language setting. The README gives JavaScript, JSON and Markdown as examples. That per-block setting drives syntax highlighting and, for supported languages, auto-formatting, so a pasted JSON response can be reformatted in place without opening a separate tool.

The README states that Ctrl/Cmd + Enter creates a new block. That single shortcut is the core interaction: you are not managing files or panes, you are splitting one continuous surface into typed regions. Language auto-detection is listed as a feature, which suggests the Language field is often filled in for you rather than chosen manually, though the README does not describe how detection decides.

The rest of the buffer-level features sit around this: multiple buffers in tabs, single-buffer and multi-buffer search, inline images, a math and calculator mode, currency conversion, dark and light themes, spellchecking, and an optional global hotkey to show or hide the window. The architecture is stated plainly in the thanks section: CodeMirror provides the editor, Vue the interface, Electron the desktop shell, with Math.js for the calculator mode and Prettier for formatting. The repository's primary language is JavaScript. That stack explains both the reach (Mac, Windows and Linux builds) and the footprint, since Electron applications ship a browser runtime.

Running Heynote from source

The README's development section is short and assumes Node.js is already installed. Check out the code, then run two commands:

npm install npm run dev

Tests use the same npm scripts. npm run test runs the suite, and npm run test:ui opens it in the Playwright UI. A build status badge in the README points at a GitHub Actions workflow named Tests, so the suite is wired into CI rather than being a local-only afterthought.

What the README does not give you is a configuration reference. There are no config keys, no file paths for settings, and no environment variables in the supplied material. The documentation lives on the project website at heynote.com/docs, and the README defers to it for the notes library location and the default key bindings. If you need to know where your data lands on disk before you trust the app with a month of notes, that page is the one to read, not the README. The repository also does not document a package-manager install path in the material provided, so treat the release page as the distribution channel and the source build as the development path.

Where Heynote is the wrong tool

The FAQ answers the mobile question with a flat no, and adds that a mobile app is out of scope at the moment. That is a boundary, not a roadmap item. If your notes need to be readable on a phone, this app does not cover that case and the maintainer has said so.

There is a second constraint implied by the design. Heynote is a single-user desktop buffer. Nothing in the README describes sync, sharing, or a server component. The persistence is local by construction, which is why the README routes the storage question to the documentation rather than answering it inline. That means backup is your problem. An Electron app that holds weeks of accumulated text in a local store is one disk failure away from losing all of it, and the project offers no sync service to fall back on.

The block model has its own friction. Because each block has one Language, a buffer that mixes prose and code means switching the Language field as you move between regions, or relying on auto-detection to guess correctly. For a long document that is mostly one thing, that is fine. For a buffer that is genuinely heterogeneous, you are managing metadata as you type, which is a different kind of overhead than just opening two files. The README also notes that contributions are merged when they fit the maintainer's vision for the app, so the feature set follows one person's judgement rather than a roadmap negotiated by users.

How it differs from a general note app

The obvious comparison is a general-purpose note-taking application, the kind built around documents, folders and a sync backend. The difference is in what the primary object is. In those apps the document is the unit: you create one, name it, and it appears in a list. In Heynote the unit is the buffer, and the buffer is closer to a workbench than to a filing cabinet. The README's own framing supports this, describing the buffer as a place for text you would otherwise paste somewhere temporary.

That inversion has consequences. A note app optimizes for retrieval months later, which is why it invests in titles, tags, search across everything and a synced index. Heynote optimizes for the next ten minutes. Search exists, and multi-buffer search is listed, so retrieval is not absent. But the design pressure is toward keeping the buffer open and putting things in it, not toward curating a durable archive. If your actual need is a searchable knowledge base you will consult next year, a document-oriented app fits that shape better. If your need is a text surface that is always there and never asks you to name anything, the block buffer is the more honest model.

A second comparison point is the editor you already have open. A terminal editor or a GUI editor with an untitled buffer can do much of this. What it typically will not do without plugins is hold that buffer across restarts while giving each region its own language mode, formatting rules and a calculator. That combination is the specific gap Heynote occupies, and it is narrow enough that the app's value depends entirely on whether you feel that gap daily.

Version cadence, licence and maintenance cost

The release history in the supplied material shows a steady cadence: v2.9.0, then v2.9.1-beta, then v2.9.1, with the beta landing roughly three weeks before the stable tag. A beta channel that precedes stable by a short interval suggests the maintainer uses pre-releases as a soak period rather than as a parallel product line. For an Electron app you run as your daily scratchpad, that is a reasonable pattern to see, because it means fixes reach stable quickly. It also means you should not expect long-term support branches; the material shows no maintenance releases on older lines.

The licence field is the item to resolve before you depend on this. The repository reports NOASSERTION, which means GitHub could not map the licence file to a known identifier. That is not the same as having no licence, and it is not the same as a permissive one. It means you have to open the licence file yourself and read it. If you plan to bundle Heynote into a commercial product, redistribute a modified build, or ship it inside a corporate image, that reading is not optional. Nothing here is legal advice, and the only reliable source is the licence text in the repository.

Upgrade cost is low by design. The app is a desktop binary, the data lives in a local notes library per the documentation, and there is no server to migrate. The real cost is the one-time verification: find the notes library path, confirm what format the data is in, and put it under whatever backup you already run for your machine. That step is worth doing before the buffer holds anything you would miss.

Editorial conclusion

Adopt Heynote if you want one always-available text buffer with per-block syntax highlighting and you are willing to keep your own backups of the notes library. Do not adopt it if you need mobile access, since the FAQ states that a mobile app is out of scope, or if you need shared editing. Before committing, verify where the buffer data is stored by reading the notes library section of the documentation, and confirm the licence terms, because the repository reports NOASSERTION rather than a named licence.

Official sources

1. heyman/heynote on GitHub
2. Issues
3. Project website
4. README
5. Releases