Wispr Flow: Dictation That Works EverywhereStop typing. Start speaking. 4x faster.
Promoted
OpenMarkdown
A markdown editor you and your agent co-edit
261 followers
A markdown editor you and your agent co-edit
261 followers
A fast, light markdown editor that opens any `.md` file instantly. Your agent reads, writes, and co-edits the same file you're in — through a CLI, an agent plugin, and MCP. Local-first: no account, no telemetry, your files never leave your disk.
OpenMarkdown
OpenMarkdown
@agent Please feel free to try our agent guidebook — an interactive demo where OpenMarkdown and your agent walk you through it together, including the live co-edit. Paste the prompt into your agent to start (just enable the openmd CLI in Settings first), and let us know if anything doesn't go smoothly~
Co-edit mode writing into the same .md file I'm actively typing in is the part I'd stress-test first — most 'agent + editor' tools use a separate pane precisely to dodge that. When the agent and I write to the same section at once, how does it reconcile: file-watch reload with last-write-wins, or an actual diff merge so my in-flight edits aren't clobbered? And since you dropped caching for RAM on Tauri 2, does peek-open stay instant on large multi-MB markdown, or is that where the no-cache tradeoff shows?
OpenMarkdown
@hi_i_am_mimo You're stress-testing exactly the right thing 😊
On reconciliation: it's not a file-watch reload with last-write-wins. Agent writes are section-scoped and land as a transaction in your live buffer. If you're both in the same section, it's optimistic concurrency — every agent write carries a hash of what it read, and if you've touched that section since, the write is rejected (not merged, not overwritten). Your in-flight edits are never clobbered; the agent re-reads and retries. The plain .md stays the source of truth.
On speed: peek-open stays instant for everyday files — dropping the cache is about not hogging RAM (personally, I'd be frustrated to see a "simple editor" eat a huge amount of it). In my own daily use I haven't hit response-time issues with large .md files.
Would love your stress-test notes~
The concurrency answers here all assume the agent sends a small edit, but in practice most coding agents rewrite the whole file even for a one-line change. When an agent edited a CLAUDE.md I was mid-sentence in, the pain wasn't a merge conflict, it was losing my cursor position and undo history to a wholesale rewrite that section-level hash-CAS still treats as one big dirty region. Do you constrain the agent to patch anchored ranges, or accept a full write and reconstruct the minimal diff yourself?
OpenMarkdown
@dipankar_sarkar Sharpest version of the question — thank you.
Short answer: both, and which one kicks in depends on whether the agent goes through our MCP tools or just writes the file itself.
- Through our MCP (write_section): the agent is constrained to an anchored range — it patches a section by heading, never the whole document (there's no full-document replace).
- Writing the file directly (the case you hit — most agents rewrite the whole thing with their bash tool): we diff the new file against your live buffer and apply only the minimal change, as a remote edit, so your cursor maps through it instead of resetting.
Honest limit: if the rewrite also reflows the whole file, the "minimal" diff stops being minimal — and keeping the agent's edit out of your undo stack is still on my list (still looking for the best design for the best user experience).
You've named the real open gap. Would love your take on anchoring that survives a reflow~
The write_section path is the clean answer, but the direct-file-write path is the one I hit most, since Claude Code and Cursor both grab their own Write/Edit before any project MCP. On that path, when the agent rewrites the whole file, does openmd diff it back down to section granularity so my undo history and cursor survive, or does the buffer reload as one big edit? That reload is what actually loses my place mid-sentence.
OpenMarkdown
@dipankar_sarkar Great question!
It diffs, it doesn't reload. The watcher takes the incoming file, computes the minimal diff against your live buffer, and applies just the changed ranges as one precise edit — so a whole-file rewrite that only really touched one section collapses back down to that section. Your cursor, scroll, and undo history ride along on everything that didn't change.
Honest caveat: it's diff-granularity, not literally "sections" — if the edit lands right where your caret sits, that spot does move. But you never eat a full-buffer reload mid-sentence.~
The co-editing angle is the interesting part. The section-scoped hash-CAS approach makes sense for simple edits, but OT and CRDTs usually struggle with the same edge case: an agent producing a large structural rewrite while a user is mid-sentence in that region. Does it fall back to last-writer-wins, or is there a way to express intent at finer granularity than section level?
OpenMarkdown
@anand_thakkar1 Thank you for the insightful question~
Not last-writer-wins — that's the line I most wanted to avoid. On a stale write (section-scoped) the agent's edit is rejected (the section's hash no longer matches what it read) and it re-reads; your in-flight text is never overwritten. So even in your edge case — a big rewrite while you're mid-sentence in that region — the agent yields, not you.
On finer granularity, we are still exploring the right approach. The applied edit is minimal-diffed, so it's small when the real change is small — but the unit of conflict is still the section, not a sub-range. Block-level scoping is likely the right next step for finer control — curious how you'd approach it. Would love your take~
Cursor and undo surviving is the big one, thanks. The follow-up that actually matters for me is undo granularity: when the agent's rewrite touches three sections at once and you apply it as one precise diff, is that one undo entry or three? The case I keep hitting is the agent nails two sections and mangles the third, and I want to Cmd-Z just the bad one without losing the two good edits. Does openmd split the applied diff into per-section undo steps, or is it atomic?
OpenMarkdown
@dipankar_sarkar This is a good one. It's atomic today — one undo entry. The rewrite comes in as a single minimal diff applied as one transaction, so ⌘Z reverts all three sections, not just one. Per-section (really targeted) undo is on my list, should be shipped in the next update. What works now: instead of ⌘Z, tell the agent "section 3 is wrong, redo just that one" — it rewrites that section (scoped + hash-checked), the two good edits stay put. Great pressure-test~
Most of this thread stress-tests the co-edit on code and CLAUDE.md, but the case I care about is prose. When I'm drafting an essay and the agent reworks a paragraph I'm mid-sentence in, the merge is the easy part — what I actually lose is voice. Agents tend to iron my phrasing into that smooth, averaged register, and because it lands as a clean diff in my own buffer it's easy to accept without noticing my sentences stopped sounding like me. Have you thought about surfacing agent-authored ranges differently from mine — a subtle tint, or a "written by agent" gutter mark — so I can see where my words end and the agent's begin before I commit? Local-first and rendering inline in the same pane is exactly the right foundation for real writing, not just notes. Nice work.
OpenMarkdown
@avantigrowthlab Aha — you've described exactly what we're building for right now. 😄
Real and in testing today: the line the agent's working on lights up live in a dedicated agent color, when done a non-disturbing banner shows, and click to jump the agent's section with highlights. The visuals are render-only; your .md stays plain GFM, no metadata baked in.
A persistent "who wrote this" mark stays off the table (it'd have to live in your file or a shadow copy — we won't). So we chase the in-the-moment version, and making it natural to peel just the agent's edit back off is next on the bench. New version's coming very soon, stay tuned 😊~
The agent's line lighting up live in its own color while the .md stays plain GFM is the right separation. "Peeling the agent's edit back off" being next is the one I'm most excited about — being able to cleanly reject an agent edit is what makes people trust letting it edit at all. Watching for the new version.
OpenMarkdown
@avantigrowthlab Thank you! https://openmarkdown.dev/#download agent editing ambient highlight is shipped in 0.12.0. Let me know how it goes~
OpenMarkdown
@avantigrowthlab Thank you for the great suggestion. Studios Release 0.12.0 now ships the "agent editing status" you both described:
the tab shows an orange dot while a file is under live co-edit
any section an agent reads or writes gets highlighted
when the agent finishes, a non-disturbing banner appears — clicking it jumps focus straight to that section
All render-only — your .md stays plain GFM, no metadata baked in.
Give 0.12.0 a try in the meantime and tell me if anything feels unintuitive~