Posted by OlaProis 1/11/2026
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!
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!
None of this should be considered critical of this project specifically, very few share "how the sausage is made". You're breaking new ground with a comment about being AI generated prominent in the README, I hope that catches on.
AI Development Workflow: Complete explanation of the process, handover system, how I manage context between sessions
Historical PRDs: The actual Product Requirements Documents used to generate tasks (v0.1.x through v0.3.0)
Task JSON files: How requirements were broken down into implementable tasks via Task Master
Handover templates: The reusable prompts I use to maintain context between AI sessions
Thanks for pushing on transparency, your comment about "open weights vs open source" is a useful framing. The goal is to share enough that someone could reproduce and learn from the approach.
I don't disagree with your sentiment, I am also more interested in human-written projects, but I'm curious about how this works. Would a new sorting network not be open source if found by a closed source searching program, like AlphaDev? Would code written with a closed source LSP (ie. Pylance) not be open source even if openly licenced? Would a program written in a closed source language like Mojo then be closed source, no matter what the author licences it under? The line between input and tool seems arbitrary at best, and I don't see what freedoms are being restricted by only releasing the generated code.
The domain knowledge still matters. AI just compresses the boilerplate time.
- Zed uses their own gpui framework - Ferrite uses egui — an immediate-mode GUI library
egui is great for rapid development but has limitations. The v0.3.0 custom editor widget is specifically because egui's built-in TextEdit blocks features like proper multi-cursor and code folding. We're not getting much "for free" there — the Mermaid renderer, syntax highlighting integration, and view synchronization are all custom.
That said, egui definitely accelerated the initial UI work. Credit where due!
>Now is the time for all good men to come to the aid of their party. >test
and selected the last and made it bold using the formatting bar.
- 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
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.
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?
That said, I've checked Ferrite out – unfortunately there's a very long way to go before it becomes Obsidian-ish (left and right panel, add tabs, hide the top formatting bar), better focus on those features. If it becomes close enough – I'll implement the encryption myself :)
- Right panel (backlinks?) would come with v0.3.0 wikilinks work
- Hiding toolbar is a quick settings addition — I'll add that to the list
What's your priority order for those? And if you do implement encryption later, I'd love to see the approach!
These "many small details" are what v0.3.0's custom editor widget will unlock. egui's TextEdit doesn't give us fine-grained cursor control, but replacing it will.
I love the new era of graphical applications in Rust.
I don't know if it's the best format to focus on.
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!
For now Ferrite is focused on Markdown since that's the most common format for notes and quick docs. But the architecture could support other formats — the parser layer is modular.
If there's demand, AsciiDoc would be the easier addition (cleaner syntax than RST). Would be curious how many folks would use it as their primary format vs. Markdown.
- 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.
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.
https://merview.com with full source code at https://github.com/mickdarling/merview