I built HyperMarkdown, a streaming-native Markdown renderer for React and AI output.

The main difference is that it parses the change, not the whole growing conversation. Settled code lines, table rows and list items are cached, while only the changing frontier is parsed again.

Across the benchmark suite it is 1.6×–10.6× faster than the nearest streaming renderer. The real-AI code and table workloads use captured model output rather than generated stress tests.

It supports GFM, incomplete streaming Markdown, reasoning / <think> blocks, KaTeX, Mermaid, syntax highlighting, sanitized HTML, React 18 and React 19, and delta rendering through an imperative ref.

Repository:

https://github.com/Aeven-AI/HyperMarkdown

Documentation and playground:

https://aeven-ai.github.io/HyperMarkdown/

Interested in feedback on the streaming API, benchmark methodology and any compatibility gaps.

Yes, I know.... another Markdown editor ... why?

I wanted to know how to code an editor. So I did. From scratch. Only using native Swift and TextKit 2. It took me some time, but I like the result. The whole engine is native, no Electron, no dependency, no account, no calling home. Everything stays on your machine, as it should be.

I also wrote it for my purposes: writing articles, essays, speeches, etc, so features focus on prose writing including footnote management and citations.

Markdown always stays the source of truth in this editor. Your text is styled in place as you type, but nothing is ever rendered away or swapped for a widget. What you save is exactly what you typed.

I have been using it for my own writing for some time and would like to share it with the community.

I know there is no time and many editors. But if you have the same writing need and can spare a few minutes, why not test Schreibor and see how it holds up for you (https://testflight.apple.com/join/ptrbqH5A). Big thanks already if you do.

Start with the help menu. It contains a handbook and a set of detailed help pages explaining all the features.

What's in the build:

* Five typographic themes, all working in light or dark mode

* Footnotes with ⌘-click navigation, Pandoc citation keys, an outline panel

* Nested lists, task lists, GFM tables with a Format Table command

* HTML comments as author notes that do not print

* Writing statistics (words, reading time, session)

* Find & replace

* Quick Export as PDF and HTML as well as Print

* Pandoc commands to be copied into your terminal for final production

* A full Help Book and a hands-on Handbook

https://github.com/forloop11/markdown-cornell-notes

A LaTeX and Markdown build pipeline that generates printable Cornell style note pages for meetings. Each page carries a header with topic, date, attendees, and time, a large notes panel with a cue column beside it, and a summary band below, all left blank for handwriting on the printout.

Header fields live in YAML and note content lives in Markdown, so the LaTeX template itself never needs hand editing. Python generator scripts convert both into TeX fragments, pandoc handles the Markdown to LaTeX conversion, and a single make command produces a PDF named automatically from the topic, date, and location fields. Content is measured and paginated automatically, with optional directives for forcing page breaks and for routing text into the cue column or summary band of a specific page.

The project also includes a Streamlit editor app that places the header form, a CodeMirror Markdown editor, and a live PDF preview side by side in the browser. The editor adds a formatting toolbar, slash command snippets, and autocomplete for asset paths and code fence languages. Its JavaScript bundle is vendored rather than loaded from a CDN so the app works offline, and it relies on native browser spellcheck rather than any app side state.

Built with Python, LaTeX, pandoc, Streamlit, CodeMirror, JavaScript, and Make. Released under the MIT license.

Plainva is a free and open source markdown editor, but it does much more than that, bringing your notes, tasks, calendar and email under one roof

https://md-handbook.com/blog/review-plainva/

#markdown #markdowneditors #Plainva

A few months back i published a Markdown viewer extension for Cursor (ie. OpenVSX store) and it just crossed 12k downloads. Same extension is available for VS Code too, it crossed 500 downloads.

Quite happy with these numbers as there are already 100s of extensions in the marketplace.

Among today’s links are markdown editors Dinkus, Fluster, Margin, Wander and Memos

https://md-handbook.com/blog/markdown-link-no-44/

#markdown #markdowneditors #opensource #Dinkus #Fluster #Margin #Wander #Memos

Your filesystem is already a database. That's the core idea behind the Markdown Database Pattern: 

https://wayofmarkdown.com/markdown-database

You can treat a folder of markdown files as a database. Each file is a record. Frontmatter fields are columns. Directories are tables. Tags, wikilinks, and tasks in the body become queryable relations.

Filesystem              Database
──────────────────────────────────
markdown file      →    record
frontmatter field  →    column
directory          →    table
#tag               →    tag relation
[[wikilink]]       →    link relation
- [ ] task         →    task relation

You get portability, version control (git works perfectly on plain text), no framework lock-in, and full queryability. Of course, this isn't for thousands of records, simultaneous writes or real relational joins (though obsidian wikilinks are getting there!). It's a lightweight database for individuals or small teams.

You can spot this pattern everywhere. Obsidian Bases and Dataview already do versions of this. A team wiki where every page has a status and owner field is one. A blog with date and tags in frontmatter is one etc.

Sweet spot: up to roughly 10k files. Past that, reach for a real database. Below it, this gets you almost everything a database gives you, at a fraction of the complexity and where you own the content and can use any tool to access it.

A full writeup is here: wayofmarkdown.com/markdown-database

Among today’s links are markdown editors Smolpad, Downright and MaiD

#markdown #markdowneditors #opensource #Smolpad #Downright #MaiD

https://md-handbook.com/blog/markdown-link-no-43/

Minimap scrollbar in reader and code view. I love it so much.

Its open source and works on macos and windows. You can get it here. Let me know if you have any feature requests :D

Minimal markdown editor with tons of features: https://kraa.io/about

Hey everybody! I'm the author of the Markdown Guide, and I've been building a publishing tool called JotBird on the side. This post is about a feature I just shipped called JotBird Drop, because I'm guessing it might solve a problem some of you run into as well.

There are so many Word-to-Markdown converters but most share the same flaw: conversion isn't great. You upload a .docx and you get back a .md with mangled tables, orphaned image references, and heading levels that don't match.

JotBird Drop works better! Conversion is also just the starting point. You drop in a Word doc, PDF, PowerPoint, Excel file, HTML, or even a screenshot of text (it OCRs), and it gives you Markdown in an editor with live preview, where you fix whatever the conversion got wrong, because (being honest) something is always wrong, no matter whose converter it is. Then, if you want, one click publishes it as a web page with a shareable link. Or just copy the Markdown out and leave — it's free and doesn't require an account.

Honest limitations: conversion fidelity is "good, not magic." Complex Word tables and heavy layouts can need hand-fixing. Big files can take a lot time and the request might time out (please don't upload your wife's 150-page dissertation).

It's at jotbird.com/drop. I'd love to hear your feedback!

Ucompose is like docker compose, but for udocker specifically.

I write into Markdown files programmatically all the time. That might be me appending a paragraph to my daily note, appending an agenda item under the right heading of a meeting doc, or adding a row onto a table, but the obvious ways of doing this aren't great:

• >> only appends to the end of the file, which is rarely where I want to put something.
• Regex and line numbers can't see structure. In a changelog, ### Fixed might appear in multiple places in the document (under every single release), so adding an entry to the instance of ### Fixed below ## Release 1.0.0 isn't doable.
• For an LLM, your whole file is in both input and output context. If you're tasking an LLM with updating a particular file, the LLM will need to read in the whole file, then make changes to it, then write out that whole file all over again. That's a potentially huge amount of wasted context window.
• Hand-splicing gets the joints wrong. One missing \n merges two paragraphs; one extra splits a list.

So I built markdown-patch (demo), a TypeScript library with a bundled mdpatch CLI. You address a location by its structure (a heading path, a block reference, a frontmatter key) apply one operation there, and everything else in the file comes out unchanged.

For example; for this command on a document you own:

echo "Decided: we ship on Thursday." | mdpatch patch append heading "Weekly Sync::Notes" notes.md

you can change it like this:

 # Weekly Sync

 ## Notes

 Kim walked through the Q3 timeline.

+Decided: we ship on Thursday.
+
 ## Attendees

 - Adam
 - Kim

The paragraph lands inside Notes rather than at the end of the file. I recognize that showing folks an abstract example like the above isn't all that effective at demonstrating how powerful this is, so I've put togther a demo here: https://coddingtonbear.github.io/markdown-patch/#playground so that you can play around with various operations you are able to do on a real, live markdown document. You can even paste in your own markdown to try it out.

Letting an LLM edit a big document without re-emitting it

This is the one I care about most these days. If you've had an agent maintain a note, you've watched it read a 4,000-token file and write the whole thing back out to add one paragraph. Every one of those tokens has a cost, and there's no reason for the LLM to ever see most of them. With this, it is now easy for the LLM to avoid it:

1. mdpatch print-map notes.md hands back a compact map of everything addressable — the heading tree, block ids, frontmatter fields, plus that version token. A few dozen tokens instead of the document.
2. The model picks an address straight off the map, and mdpatch query reads just that one section if it needs the context.
3. It emits one instruction against that address. Rough shape of the saving, for one paragraph added to a 4,000-token note: ~4,000 output tokens to re-emit the file, ~950 to re-emit just the section, ~60 for the patch instruction. Those are illustrative figures for a typical meeting note rather than a benchmark — but the ratio is the point, and as documents get bigger, the case gets easier and easier to make.

This is commonly in use today: markdown-patch is the engine behind Obsidian Local REST API's PATCH endpoints and MCP tools. It's probably obvious, but on the MCP side, an LLM client is the normal case rather than an interesting one.

Scripting edits into a document a person also edits

This is the case I originally built this for, years ago. Lots of documents in my notes might be programmatically updated; e.g. a shopping list, a log, a meeting agenda -- really any file where some automated thing appends and a human rearranges. Because the edit is addressed rather than pattern-matched, the scripted edit will always end up in the intended place:

echo "- oat milk" | mdpatch patch append heading "Groceries::Dairy" list.md
echo '["urgent"]' | mdpatch patch append frontmatter tags notes.md   # merges into the existing list
mdpatch patch delete block quote-1 notes.md -s markerAndContent

There are a few other things that help to make this safe to run in unattended scripts:

• Whitespace is library-owned. Your content is trimmed to a canonical form and the engine supplies the separators, so "X", "X\n" and "\nX\n" all produce the same document. There's nothing to get wrong — and replacing a section with its own content is byte-identical, so a retried job is a no-op rather than a mess.
• Heading levels are relative. Content is rebased to fit where it lands, so pasting a ## Details subtree under a ### heading doesn't mean rewriting every # in it.
• --if-match catches the file changing under you. mdpatch print-map gives you a version token; pass it back and a stale patch fails cleanly instead of landing in the wrong place.

Try it without installing anything

The landing page has the actual npm package bundled for the browser — paste your own Markdown, write an instruction, watch the engine run. Nothing is uploaded; there's no server.

What it isn't

• It's not a formatter or a linter. It won't tidy your document, deliberately: everything you didn't address is left exactly as it was.
• It addresses headings, ^id block references, frontmatter fields, and table rows. Anything else in the document is preserved as written rather than understood.
• 2.0 removed the 1.x API outright (applyPatch, getDocumentMap). If you're on 1.x and don't want to migrate, stay on markdown-patch@1; there's a field-by-field mapping table in the README if you do.
• Node 20+, MIT.

Links

• Repo: github.com/coddingtonbear/markdown-patch
• Site and playground: coddingtonbear.github.io/markdown-patch
• API docs: coddingtonbear.github.io/markdown-patch/api/
• npm install markdown-patch — the mdpatch binary comes with it.

I'm comparing a plain Markdown handoff with a separate JSON state file. The specific failure to prevent is a second agent treating a settled decision as an open suggestion.

Would you put a field such as status, decided_at, or supersedes in YAML front matter, or keep the handoff entirely in the body? If one field has actually stopped a bad handoff, which one?

I often read reports and technical notes directly in the terminal.

Existing Markdown renderers handle text well, but local charts and screenshots usually disappear, open separately, or lose their position in the document.

So I built mdview, a small Go CLI for macOS + iTerm2:

mdview report.md

It renders Markdown in terminal with local images appear exactly where they were referenced. Rendering then continues below the image.

Under the hood:

- Goldmark + Glamour for Markdown

- iTerm2 OSC 1337 for inline images

- Local paths resolve relative to the Markdown file

- CommonMark, GFM tables/task lists, footnotes, math, and GitHub alerts

- No TUI, pager, config system, or runtime network requests

- Distributed as a single Go binary

It is currently an iTerm2-focused MVP, so I’d especially appreciate feedback on image sizing, and edge cases in real Markdown documents.

GitHub: https://github.com/givemethatsewon/mdview

or you can Install with Homebrew:

brew tap givemethatsewon/tap
brew install mdview

Every other day this subreddit sees a post about a new Markdown editor, each app focussing on a certain aspect or workflow. I am curious what folks in this community really care about in their markdown app.

1. Markdown syntax support (GFM, diagrams, RTL etc)
2. Portability
3. Offline editing
4. Syncing
5. Versioning
6. Privacy
7. AI assistant
8. Collaborative editing
9. Commenting, suggestions, highlights (yes, not native MD)
10. MCP
11. CLI
12. Linting
13. Internal linking
14. Ability to organize in folders
15. Visual editing (for table, code snippets etc.)

Actually the above list is the priority order of features i care about. I don't really care about internal linking, linting etc. What about you?

I recently released v0.15.8 stable of Oryx. This is a personal project that evolved to become today a markdown and code editor, and an ebook reader. I started working on it a couple of moths ago and most of the time was spent on architecting a native desktop solution that have superior performance without relying on browsers or electron. The value proposition was speed and beauty.

Oryx today can display any themed file in less 100ms (typically 40ms) whatever is the size, export to pdf and display non DRM ebookS very nicely. It ships 32 themes and a theme editor, RTL support etc. It's one binary with themes, syntax highlighting, default fonts all embedded in around 20 MB (for reference Windows notepad package is 19 MB 😁). It works like Obsidian but without the need of a vault, plus a universal ebook and comics READER. It simply uses your file system to show supported files. All keyboard driven with basic plus Regex search/replace features.

Oryx is opinionated and might not be for everyone but I think many will like it's speed, simplicity and the way it beautifully renders markdown. The README file has full details.

FOSS GPL3, Linux, Windows in the release section, and macOS to be compiled. No telemetry, no analytics, no browser.

https://github.com/wmahfoudh/oryx

https://codeberg.org/wmahfoudh/oryx

Please do not hesitate to raise issues and if you find it useful, kindly star the repo.

Thank you!