My first post in four years! And, interestingly, on a similar topic as my last post.

Zed, the editor I raved about in my last post, is now essentially abandoned and unmaintained by its author. This is understandable given the direction his career has taken, but is also a bit unfortunate given its innovative approach to editing.

I've since been bouncing around using some other editors, including Atom, VS Code, and most recently Sublime Text 3. In all three cases I've configured them to function as similarly to Zed as possible, but it's never been quite right. Under the hood, all three editors still assume an "open dirty buffer" model of document management, and this leaks out from time to time.

Despite the shortcomings, I've been mostly okay with this state of affairs. But there are nevertheless some things that annoy me:

1. Both Atom and VS Code are built on top of web technology. I don't like my editors taking up hundreds of megabytes of RAM with only a couple of text files open. That's just silly. And in Atom's case, it has chuggy performance to boot.
2. Sublime Text isn't open source. I don't mind paying for software (and happily did in Sublime Text's case), but I always feel nervous about committing my workflow to software that doesn't belong to a larger community.

Because of these annoyances, a few years ago I developed an interest in writing my own editor. This sounds completely silly, and it pretty much is. Nevertheless, the journey of creating my own editor has been really interesting, and I've learned a lot of cool things.

Realistically, I don't think the editor will become anything worth using, but it's a really fun exploration, and I want to share that. I have more to share than will reasonably fit in a single post, so this will be the first post of (probably) many.

Led

My editor is called Led, which can stand for "Lousy Editor", "Loser's Editor", "Laughable Editor", or any number of other derogatory phrases that start with "L" and end in "Editor". In its current state Led is a console-based editor that:

• Can load text files faster than even Vim. A 1GB file takes approximately 1.5 seconds to load on my machine, vs 2.5 seconds for vim.
• Can edit said 1GB text file without breaking a sweat. (Including when it's all on one line!)
• Supports real time word wrapping that you never have to wait for. (Even with the afore-mentioned 1GB all-on-one-line file!)
• Correctly handles Unicode text, including graphemes and double-width characters. (However, it doesn't do bidirectional text.)
• Recognizes all Unicode line endings (there are eight of them!).
• Has basic undo/redo functionality.

All-in-all, it's an extremely bare-bones editor, but that has some really robust characteristics. I would absolutely not want to use it for any real editing tasks, but it feels pretty great that in the realm of bare-bones-only text processing it beats out every other editor I've tested it against. Essentially, Led can open and happily edit any utf8 file you throw at it, as long as it will fit in RAM, no matter how weird. Every other editor I tested (including Vim, Sublime Text, emacs, etc.) chokes in at least some corner cases.

Personally, I think that's pretty cool, and I'm reasonably proud of it. Makes me feel like a good software engineer! But obviously, it has a long ways to go to be useful.

Vision

My lofty vision for Led, which will likely never come true, is basically to create a better Zed. Zed made some great UX decisions, but was implemented on top of web technology. Creating a native-code clone would itself be a nice boost, but in the process of developing Led I've come up with some additional things that I want to explore.

The main thing I want to explore is a more expansive view of what is considered "the thing you're editing". Every editor I've ever encountered considers a text file as the thing you're editing. But I think in reality the thing you're editing is the entire code base.

Now, I'm not saying that code editors aren't multi-file aware. Obviously, most are! In fact, every good code editor I've used allows you to work with some kind of project or directory concept. But editing operations aren't treated at that level. The primary experience I've had that makes this apparent is when you do a project-wide search-and-replace: there's no "undo" operation for that. And that makes such operations pretty scary. For most editors this situation is understandable: an undo operation that applies to multiple files raises a lot of questions, like what the state of all the touched files should be afterwards. Saved? Loaded and dirty? Some other weird special-cased concept?

Zed's approach to editing eliminates most of those questions entirely. Buffers are never dirty, undo is infinite and persistent, etc. With that approach you can treat the entire code-base as a single item that just happens to be subdivided into files. Then operations like multi-file search-and-replace, refactor operations, etc. are like any other editing operation, and can be undone, redone, etc. just like anything else.

In such a system, undo within a single file is just a special case: you're selectively undoing within an area. And you could take that even further: if you can selectively undo within a single file, why not within a selection? I cannot count the number of times I've made some edits in one place in a file, then done some unrelated edits elsewhere in it, and wanted to temporarily undo the first edits while testing the second edits. It actually happens quite a lot. Being able to select an area and undo within that would be great!

With this approach, all operations become something that function within a scope, which can be as large as the entire project, or as small as a tiny selection. This would make everything, not just undo/redo, potentially much more powerful.

The default scope for things should probably still be the currently active file. But this concept unifies a lot of things that are otherwise disjoint and strange. I would like to explore how to make something like this work in practice.