I Rebuilt the Foundation of My Text Editor

After working on cdin for a while, I started noticing something.

The biggest problems were not the features I was missing.

They were the things underneath.

When I first started cdin, the goal was simple: build a small, fast, and hackable text editor that works well even on low-end hardware.

It started as a fork of lite, but over time it became something more personal. I changed the things I did not like, added the things I needed, and slowly shaped it into the editor I wanted to use.

But as the project grew, I noticed that some parts of the architecture were becoming harder to maintain.

The Lua layer was doing too much. Some systems had duplicated logic. Plugins depended on internal behavior instead of clear APIs. Even the event system, which was originally created to make communication easier, eventually became another layer I had to fight with.

So instead of adding more features, I decided to improve the foundation.

That is what v0.1.0-beta.5 is about.

This release is not focused on adding a huge number of new user-facing features.

It is about making cdin cleaner, simpler, and ready for the future.

One of the biggest changes was removing the old event system.

Instead of components communicating through hidden events, cdin now moves toward clearer APIs and dedicated modules.

Some of the new core systems include:

• core.state for managing runtime state
• core.project for project lifecycle and project operations
• core.git for centralized Git integration
• fs API for filesystem operations
• search API powered by the native C search engine

The goal was simple:

Make cdin easier to understand, easier to extend, and easier to maintain.

Another important change was improving the relationship between C and Lua.

The C side now handles more low-level and performance-sensitive operations, while Lua focuses on editor behavior, configuration, and customization.

This keeps cdin flexible without turning Lua into another complicated core.

The plugin system also received a lot of improvements.

Instead of relying on hidden initialization behavior, plugins now have a clearer lifecycle. Document extensions were also moved from monkey-patching to structured hook tables, making future extensions more predictable.

Other improvements in this release:

• Redesigned status bar with Vim mode indicator
• Git information integrated into the UI
• Better project search with highlighted matches and context
• Improved tabs and windows management
• New built-in theme
• Unified logging system for C and Lua
• Various platform and build fixes

This release is not about adding more complexity.

It is about removing unnecessary complexity.

Building software is not only about adding features. Sometimes the hardest and most important work is going back, understanding what no longer fits, and rebuilding the parts that nobody sees.

With v0.1.0-beta.5, cdin has a much cleaner foundation for what comes next:

• More powerful plugins
• Better project workflows
• Advanced automation
• Improved language tooling support

There is still a lot I want to improve, but cdin is slowly becoming the editor I originally wanted to build.

If you like the idea behind cdin, consider giving it a star or forking the project. It helps the project get discovered and motivates future development.

If you find a bug, have a suggestion, or want to contribute, feel free to open an Issue or Pull Request on GitHub.

For more personal suggestions or discussions, you can also reach me at:

[e-mail]

Repository:
https://github.com/m-mdy-m/cdin

Releases:
https://github.com/m-mdy-m/cdin/releases

Install:

WINDOWS: cdin-v0.1.0-beta.5-windows-x86_64.zip
LINUX: cdin-v0.1.0-beta.5-linux-x86_64.tar.gz

Thanks for checking out cdin.

Comments

[Luis Cruz]

Great engineering journey. Rebuilding the foundation of a text editor is a perfect example of how software architecture decisions made early can shape everything that comes later. Performance, extensibility, and maintainability usually depend more on the core model and internal design than on the visible features.

I like the focus on improving the foundation rather than continuously adding features on top of technical debt. Editor systems are especially challenging because they combine complex state management, rendering performance, input handling, and user expectations around reliability.

Excited to see how this new architecture enables future capabilities. Sometimes the biggest improvements come from rebuilding the parts users never see. Great work!

[Genix]

Thank you! I completely agree.

For cdin, I learned that sometimes the most valuable improvements are the ones users don't directly see. Reworking the architecture was challenging, but having a cleaner foundation makes future features and extensions much easier to build.

Thanks for the support and for sharing your thoughts!

[Genix]

Thank you for the kind words! I really appreciate it.

Thanks for the invitation, I’ll join the developer chat. Looking forward to connecting with other developers there!

[Alex Shev]

Rebuilding the foundation of an editor is one of those changes where the payoff is mostly future optionality. Users may not notice the architecture directly, but every later feature becomes cheaper if the core model is clearer. The trick is keeping the rewrite small enough that it still ships.

[Genix]

This rewrite was absolutely necessary; since the beta version was for CDIN, it still has very few users or rather, practically none so I have made extensive changes. I also strongly agree with what you said.

[Alex Shev]

Rebuilding the foundation is usually the unglamorous work that makes future features possible. The visible editor may not change much at first, but the internal model starts answering different questions: what is state, what is rendering, what is persistence, and where can complexity stop leaking upward?