Everyone has their opinion. This is mine.
First, building an editor that is better than VIM is quite easy: avoid VIM and modal-based editing.
Perhaps I'm an alien, or perhaps VIM users are aliens, but there is no reason for modal-based editing.
Modal-based editing is unnatural. If I want to do something, I shouldn't have to first think about what "mode" I'm in. That's dumb and slows users down for no reason.
Every modern editor uses keyboard shortcuts, just like Emacs pioneered back in the day, and that's how all terminal editors should be (as long as their user-interface is a keyboard).
Don't think I'm going to spare Emacs either.
It might've been the best thing around back in the day, but by today's standards, that award goes to Zed.
An editor should "just work", and Emacs doesn't.
Using emacs is like getting a house that consists of a foundation, and several piles of wood and boxes of nails and tools.
That's Emacs.
I want a source code editor, not the tools to build a slightly crappy source code editor.
The problem with Emacs is that although it is "extremely powerful" thanks to the ability for anyone to extend it as they please, this is NOT an OK design for building a great editor.
Even if you use "emacs starter kits", you'll quickly discover that they're a PITA, and this PITA comes from the fact that Emacs has no hard and steadfast rules for how to extend it. It gives everyone the ability to do whatever they want, however they want, and this quickly turns into a furball mess of a nightmare.
We need strict rules for doing everything.
It's absurd that if I want to set the indentation level to 2 spaces in Emacs, I have to think about potentially 50 different "modes" and "variables" to do that. There isn't a single variable to adjust. There's an uncountable and unknowable number of variables, because each package does its own thing and uses its own stuff.
And sometimes these things just kind of step on each other's toes. So if you want to use Package A with Package B, sometimes they just don't work well together, because nobody is following any hard rules for how to create their packages, it's all just a random mishmash of elisp, a garbage Lisp btw that is bascially Common Lisp, another crappy Lisp (which still puts it head and shoulders above most other languages).
Micro is a great example of a decent starting point for a modern terminal editor. Its copy/paste and mouse integration are excellent.
However it is too primitive, and its extensibility is too limited.
We need something like Emacs, but a well designed Emacs. Basically Zed for the terminal.
The reason why Zed is so amazing is because it does everything, and it does almost everything correctly. It's well designed. It's extensible. And it's not a cluttered difficult-to-use mess.
So create a powerful plugin system, where plugins and the editor can seamlessly interoperate together, and can powerfully extend the editor, but without each plugin having to re-invent the wheel for whatever settings its needs. Every plugin should work smoothly with every other plugin, and each should use as many settings from the editor itself as opposed to providing its own little world of configuration. Whatever configuration the plugins do offer need to be truly unique to their use-case.
Allow the plugins to work together, but make sure there are clear rules about how this is done.
Everything should "just work" on every system and with the absolute minimum intervention from the user.
Choose either Go, V (V is like Go but better), or Scheme.
Rust and Zig are disqualified for bad syntax. Zed's greatness comes in spite of its choice of Rust, not because of it (although Rust certainly has its upsides when compared to something like C++).
For extending the editor, use a simple programming langauge that is powerful. Use something like Janet. Maybe Scheme.
Lisps are a fantastic choice. Some will say to use Lua, but Lua isn't 0-based indexed, and its syntax is a bit verbose, although it's simple (do we really need to write out end instead of ) or }?).
You don't need syntax. You need design!
You could also stick with the language the editor itself is written in.
And if you really want something else, choose JavaScript. Whatever. 🙄 (But use Deno!)
Use a common storage format for storing your user's preferences.
Zed's choice of JSON here is excellent. JSONC would be even better. TOML is also great.
Enforce this format for both the editor's settings and plugin settings.
NOBODY SHOULD BE FORCED TO USE A PROGRAMMING LANGUAGE TO CONFIGURE THEIR EDITOR!
If there's a bug with a plugin or the editor itself, make this information easily accessible to both users and AI tools.
Your machine shouldn't be compromised just because you decided to try out a new theme or a new table editing plugin.
AI agents are incredible. Make it easy for them to interact with the editor.
How do users discover the editor's features? How do they learn the default keyboard shortcuts?
...A menu! I'll leave it up to you to decide whether it should be a menubar or a popup menu.
Everyone's got opinions, but some people's opinions are just wrong.
Why is Zed succeeding? Because it's got opinions, and they're the right ones (comparatively speaking).
This is the sort of wisdom you only get with experience, so learn from the experience of others. I've over two decades of experience writing software in various languages using various editors. These aren't just "opinions", they're battle scars.
Let me know when you get it done. I've been looking everywhere for a decent terminal editor and I can't find one.