Emed: My own code editor
A long time ago, somewhere I read that just as it's said that a man in his life must write a book, plant a tree, and have a son, a respectable programmer must write his own text editor. It was an idea I'd had in mind for many years, but more recently since I got interested in writing code at a "slightly lower level." But I never got to work on it; nothing had pushed me to do so until, just as I tried (and failed) to get on the mechanical keyboard train, I tried to deeply explore Neovim for editing code in the terminal. When I realized there must be a good reason I hadn't taken a liking to vi or emacs in 25 years (since my high school days, when I first experimented with programming) and that it was probably because I'm not interested in memorizing an infinity of key combinations, I knew it was maybe time to plant that tree. Or have that son. Figuratively, of course—I already have a son.
Origin
The initial idea was quite simple: I wanted to use something in the terminal that was easy to use, required no configuration, and had predictable and "compatible" key combinations with my fingers' muscle memory. Ctrl+S to save, Ctrl+W to close tab, Ctrl+F to search, etc. I first tried several existing options—which there are—including Zellij configurations with a file list in one panel and an editor in another. Nothing pleased me.
I got to work, and in a few days I was already playing with a first prototype of the editor, which I temporarily named "Emed." That first prototype I made completely from scratch, but as months passed, I started incorporating AI agent development tools into my projects, and that also ended up accelerating Emed's development quite a bit. Emed doesn't come close, not even remotely, to what editors like Emacs or Neovim offer, neither in features nor customization. Nor in stability, perhaps. But that's precisely the idea. It doesn't try to compete with that; it tries to avoid it. It's an editor that opens and just works, without needing to prepare it beforehand.
What is Emed
The interface follows a fairly standard layout: file explorer on the left, editor in the center, and terminal at the bottom. There's no innovation in that; it's basically what already exists in any desktop IDE, but brought to the terminal without extra layers on top. Navigation between panels is direct, and the key combinations or "shortcuts" are few.
The file explorer allows the basics: open, create, rename, delete, and move files using combinations we're used to: Ctrl+C and Ctrl+V to copy a file, Ctrl+X to cut (move it), etc. The editor supports multiple tabs, saving, and syntax highlighting. It even has a very capable terminal. My past self wouldn't believe I made Emed if he saw it in its current state.
There are also some additional things I added because I needed them, like searching within files and across the entire project, Git integration to see blame, and support for tools like LazyGit within the app itself. None of this is particularly polished, but it works well enough to use every day.
For the curious, some technical details: Emed is built on tview for the terminal interface, uses Chroma for syntax highlighting, and combines creack/pty with a fork of vt10x to implement the embedded terminal. tview does almost all the heavy lifting in terms of layout and rendering, though along the way I ended up modifying some things and even sending a PR to improve clipboard pasting in certain terminals like Alacritty. The text editor and file explorer are custom components, including a file tree I had to implement from scratch to better support long names and maintain state between updates. Syntax highlighting went through several attempts before settling on Chroma, and the terminal has probably been the most complicated part, especially everything related to colors, mouse events, and differences between terminal emulators. With this project, I lost my virginity with code agents: I was stuck with a horrible tree-sitter implementation and a terminal that kept hanging, but Claude Code came to the rescue (though at that stage it served more as a guide, since when trying to implement advanced things it would just go in circles and burn tokens like crazy).
The name
The name came naturally: Emed, from EMmanuel + EDitor. I didn't think much about it at the time, but later it hit me that it sounds a bit pretentious. To compensate, I ended up adding a list of alternative meanings for the acronym, shown randomly below the logo when no file is open—most of them absurd.
Current state
Although I use it a lot, it's still an experiment. There are bugs, weird behaviors depending on the terminal or system, and parts of the code that clearly need cleaning. The terminal, for example, works well in most cases, but there are still TUI apps that don't render correctly or require special handling.
There's no guarantee of stability or compatibility. Even so, it's usable enough that I prefer it over other options in my current workflow, at least in the terminal. I won't lie: my favorite desktop editor is Zed, but when I have to edit code in the terminal—which I do very often, mainly when working on my home server—I already have Emed.
Yesterday, after a little over a year in private development, I made the repository public on GitHub: https://github.com/laborin/emed. If you want to try it, go ahead, but keep in mind it's still an experiment.
I don't have a defined plan for the project. The last two things I added were integration with Claude Code and LazyGit. I might keep improving it; it occurs to me that an integration with Codex would be more useful now, which I've been using more than Claude Code lately. For now, it fulfills its function, and that's enough.