I’ve wanted to build a text editor for a long time. Not because I thought the world needed another one — it clearly doesn’t — but because editors are one of those projects where you end up touching everything: rendering, input handling, text buffers, undo, plugins, configuration, even OS integration. It felt like the most honest way to learn how these tools actually work.
So I finally did.
cdin is a lightweight, keyboard-centric text editor with Vim-style modal editing. It started as a fork of lite, but over time it became something more personal. I kept the parts I liked, removed the parts I did not, and reshaped the rest to match the way I actually work.
A big reason for that was my computer. I have a weak machine, and that made heavier text editors feel frustrating to use. They were often slow, laggy, or just too much for what I needed. That is how I discovered lite in the first place. It was close to what I wanted, but not quite there. So I forked it, renamed it to cdin, and started making it mine.
That meant more than just small tweaks. I removed features I did not need, changed the things that felt awkward, moved from SDL2 to SDL3, and rewired a lot of the project structure along the way. The result is cdin: a small editor built around speed, simplicity, and hackability.
The name itself is simple too. cdin means “CODE in”.
The code is split between C and Lua. The C side handles the window, renderer, and SDL bindings. Everything else — behavior, plugins, keybindings, config — is loaded in Lua at runtime. That keeps the editor flexible without making it feel heavy.
If you want to explore the project, here are the main docs:
Overview · Getting Started · Building from Source · Configuration · Vim Keybindings · Plugins · Command Reference
There is still a lot I want to improve, but cdin already feels like something that belongs to me in a way no other editor ever did.
If you check it out, please leave a star, fork it, or send an Issue or PR if you find a bug or want to help make it better. Feedback means a lot.
Repository: https://github.com/m-mdy-m/cdin
Top comments (17)
Neat
Thanks!
I think the links are broken, Id love to give it a try!
Which links?
Here is the repository link:
github.com/m-mdy-m/cdin
And here is the release link for downloading:
github.com/m-mdy-m/cdin/releases/t...
Windows:
github.com/m-mdy-m/cdin/releases/d...
Linux:
github.com/m-mdy-m/cdin/releases/d...
Thanks! I think it was from dev.to cause it lead directly to docs but they seem to work now
If you use it, I’d love to hear your thoughts!
You were right; the links were broken.
I had forgotten to add "github.com/m-mdy-m/cdin/blob/main"!
Been down this path with small tooling editors. SDL/input layer ends up being most of the work.
Lua for config keeps it flexible without bloating the core.
Low-end hardware focus is underrated.
That’s great. I’m glad to hear you’ve worked with SDL! So, have you tried cdin? What do you think of it? I’m really keen to see what the UX/DX of cdin is like!
good luck
thanks
Such a great personal passion project! It’s refreshing to see someone build an editor just to learn the internals, not just to fill a market gap.
The lightweight SDL3 foundation + C/Lua split is perfect for low-spec hardware, and stripping Lite down to match your own workflow makes total sense. Vim-style modal editing on a tiny fast editor is such a underrated niche.
Love the simple “CODE in” naming—straightforward and memorable. Gonna pull the source and try it out later, left a star already!
Thank you so much! I really appreciate your kind words and I’m glad you liked the project. 😊
I think there might be a small issue though I can’t seem to see the star on the repository. Maybe GitHub didn’t register it or there was a problem while starring it.
Either way, thank you for checking out CDIN(CODE in) and for your support! If you try it and have any feedback, criticism, or suggestions, I’d really love to hear them. Any ideas that can help improve the project are always welcome. 🙌
Building something just to understand how it works under the hood is underrated. You always come out knowing way more than you expected.
I completely agree. Building something from scratch just to understand how it works under the hood is one of the best ways to learn. It forces you to face the real problems, understand the trade-offs, and discover details that reading documentation or watching tutorials rarely teaches. Even if you never use what you built in production, the knowledge and intuition you gain are incredibly valuable and stay with you for a long time.
Wow
What do you think about it? 😁😁😁