Show HN: Ferrite – Markdown editor in Rust with native Mermaid diagram rendering
241 points| OlaProis | 2 months ago |github.com
Built a Markdown editor using Rust + egui. v0.2.1 just dropped with major Mermaid improvements:
→ Native Mermaid diagrams - Flowcharts, sequence, state, ER, git graphs - pure Rust, no JS
→ Split view - Raw + rendered side-by-side with sync scrolling
→ Syntax highlighting - 40+ languages with large file optimization
→ JSON/YAML/TOML tree viewer - Structured editing with expand/collapse
→ Git integration - File tree shows modified/staged/untracked status
Also: minimap, zen mode, auto-save, session restore, code folding indicators.
~15MB binary, instant startup. Windows/Linux/macOS.
GitHub: https://github.com/OlaProeis/Ferrite
v0.2.2 coming soon with performance improvements for large files. Looking for feedback!
[+] [-] random3|2 months ago|reply
It would be interesting to know more about the end-goal if any.
Best of luck! I'll watch this.
[+] [-] OlaProis|2 months ago|reply
[+] [-] kirubakaran|2 months ago|reply
(I'm not quite ready to do a Show HN yet, so please don't post it, but I'm ready for some early feedback if you'll indulge me)
[+] [-] echelon|2 months ago|reply
[+] [-] rkagerer|2 months ago|reply
Neat! Lately on Windows I've felt like a 2nd class citizen.
> AI Disclosure: This project is 100% AI-generated code.
Oh.
Well, at least they're up front about it.
[+] [-] dystroy|2 months ago|reply
[+] [-] rajatkulk|2 months ago|reply
[+] [-] weakfish|2 months ago|reply
[+] [-] msephton|2 months ago|reply
I find it makes sense to take screenshots in a window big enough to show what's going on, but no bigger. This means probably not full screen, or maximised, especially if you're running at a very high resolution. If there's a lot of dead/empty space in the window that's a signal it's too big. This way you guarantee the screenshots are readable without zooming in, on smaller displays than your own, for example mobile.
[+] [-] OlaProis|2 months ago|reply
I'll retake them with a more focused window size and less dead space. Appreciate the specific guidance!
[+] [-] deviation|2 months ago|reply
[+] [-] password4321|2 months ago|reply
[+] [-] djvdq|2 months ago|reply
In one second I went from "looks cool" to "I don't want to touch it"
[+] [-] Arubis|2 months ago|reply
[+] [-] gregman1|2 months ago|reply
[+] [-] OlaProis|2 months ago|reply
[+] [-] vunderba|2 months ago|reply
[+] [-] huevosabio|2 months ago|reply
How did you find working with egui?
[+] [-] OlaProis|2 months ago|reply
[+] [-] koakuma-chan|2 months ago|reply
Claude Code would have preferred React.
[+] [-] bananaboy|2 months ago|reply
[+] [-] quintu5|2 months ago|reply
[+] [-] OlaProis|2 months ago|reply
[+] [-] silcoon|2 months ago|reply
[+] [-] OlaProis|2 months ago|reply
[+] [-] WD-42|2 months ago|reply
[+] [-] dcreater|2 months ago|reply
[+] [-] _flux|2 months ago|reply
[+] [-] OlaProis|2 months ago|reply
[+] [-] Bishonen88|2 months ago|reply
[+] [-] OlaProis|2 months ago|reply
But this wasn't "2 sessions" — Ferrite has been in development for months with ~30,000 lines of Rust across 50+ modules. The Mermaid renderer alone is ~6000 lines of layout algorithms (Sugiyama-style graph layout, sequence diagram activation tracking, nested state machines, etc.).
AI helped ALOT, but there's no "generate full app" prompt that produces working text editors with native diagram rendering, rope-based text buffers, and custom window chrome. Still takes understanding the domain.
That said, you're right that the development velocity is higher than 5 years ago. Exciting times!
[+] [-] risyachka|2 months ago|reply
[+] [-] sean_pedersen|2 months ago|reply
[+] [-] OlaProis|2 months ago|reply
[+] [-] WillAdams|2 months ago|reply
[+] [-] nurettin|2 months ago|reply
[+] [-] OlaProis|2 months ago|reply
[+] [-] OlaProis|2 months ago|reply
- CJK font support 1 — Korean/Chinese/Japanese characters now render properly
- CLI improvements (#9, #10) — ferrite file.md now works, plus --version and --help flags
- Undo/redo fixes 2 — Fixed scroll reset and focus issues
- Default view mode setting 3 — Can now set split/preview as default
- Configurable log level 4 — Reduce stderr noise
- Ubuntu 22.04 compatibility 5 — .deb now works on 22.04+
Thanks to everyone who reported issues! Download: https://github.com/OlaProeis/Ferrite/releases/tag/v0.2.2
[+] [-] cat-whisperer|2 months ago|reply
[+] [-] dystroy|2 months ago|reply
Termimad isn’t a full-fledged TUI framework. It can be used to build TUIs (I made broot, bacon, safecloset, etc. with it), but if you want to quickly build a TUI and compose UI components and widgets, you’ll probably find it much easier to choose a real TUI framework (e.g. ratatui).
Termimad isn’t a generic Markdown viewer either. Markdown is mainly used as a language for the developer to describe parts of the interface—especially rich text—inside a TUI. People interested in rendering arbitrary Markdown files will find that it lacks features such as image rendering.
[+] [-] k_bx|2 months ago|reply
[+] [-] OlaProis|2 months ago|reply
However, files are stored as plain text, same as Obsidian/VS Code/any text editor. Encryption at rest isn't currently on the roadmap.
For encrypted storage, you might consider: - Using Ferrite with an encrypted volume (VeraCrypt, LUKS, FileVault) - git-crypt for encrypted git repos
That said, if there's strong interest in built-in encryption (vault-style or file-level), I'd love to hear more about the use case. Would you want password-protected vaults? Per-file encryption? Something else?
[+] [-] Levitating|2 months ago|reply
I love the new era of graphical applications in Rust.
[+] [-] mgaunard|2 months ago|reply
I don't know if it's the best format to focus on.
[+] [-] OlaProis|2 months ago|reply
We chose Markdown because: - It's what most developers already use (README files, documentation, wikis) - Plain text files are portable, grep-able, git-friendly, and won't lock you in - GFM covers tables, task lists, strikethrough, and autolinks which handles 90% of use cases
We also support JSON, YAML, and TOML with native tree viewers. Wikilinks ([[links]]) and backlinks are planned for v0.3.0 for folks wanting Obsidian-style knowledge bases.
That said, I'd love to hear what format you'd prefer — always interested in expanding support!
[+] [-] tapirl|2 months ago|reply
[+] [-] porjo|2 months ago|reply
- wysiwyg editor (not live preview)
- simplicity: single binary that can be pointed at a directory of markdown files
- fast launch time, low latency UI
- cross platform
- comes with basic 'extras' like tables & code block support
I actually really like the Confluence editor experience. If I could get that in an FOSS 'offline' package, my needs would be met.
[+] [-] OlaProis|2 months ago|reply
Single binary — ~15MB, point it at a directory with ferrite ./notes/ or open workspace via UI
Fast launch, low latency — Native Rust/egui, instant startup, no Electron
Cross platform — Windows/Linux/macOS
Tables & code blocks — GFM tables, syntax-highlighted code blocks (40+ languages)
WYSIWYG — This is where it gets nuanced. Ferrite has three modes:
- Rendered mode — Click-to-edit rendered Markdown (closest to WYSIWYG)
- Split view — Raw editor + live preview side-by-side
- Raw mode — Plain text editing
It's not pure "type and it formats inline" like Typora or Confluence. The Rendered mode lets you click elements to edit them, but it's not seamless WYSIWYG yet.
If you're looking for true inline WYSIWYG, Typora is probably closest. But if split view + rendered mode works for you, give Ferrite a try — it hits the other criteria well.
[+] [-] mickdarling|2 months ago|reply
https://merview.com with full source code at https://github.com/mickdarling/merview