I've seen a million and one text editors, and almost all of them offer the feature of being "fast <rocket emoji>" or "gpu driven" or "cleanly implemented" (now "AI integrated"; LOL). Never features that users actually care about. Perhaps this is just my ego taking, but I think I would struggle to develop such an app. What is the point in programming if you aren't presenting the user with anything new? I suppose the collaborative features in this are almost novel, but they seem misguided. It relies on other people using the same text editor as you, which is going to be quite difficult to organise.
How about a text editor which represents code as a syntax tree that is formatted as you type? Or one that has support for embedding multi-media content within source files? Or one with advanced program rewriting capabilities (in-lining functions, replacing struct members into getter methods, etc)? These things would all change the a user's experience much more than replacing the CPU rendering with GPU rendering. A text editor is the window through which we interact with code. It is an immensely rich domain for experimentation, yet the best most come up with is "what if there was a 10ms smaller latency on keyboard input?"
I think the issue here is one of perspective. As programmers, we see the code. We tend to put more focus on the features that took us the longest to implement. But often, these are not visible or relevant to the user. We like to show off the 80% of the effort that gets 20% of the outcome rather than the 20% that yields 80%. I think there's also a measurability bias at play. It's easy to make the case that a faster thing is better than a slower thing, but harder to make the case for an interesting feature. One is measurable but the other is not.
I've been using Emacs for ages. The performance is probably somewhat below average, but I just learned to ignore it. Having better editing features is worth more to me than responsive keyboard input. It would be nice to have both of course, but I don't think switching to a different editor would be worth it for me.
The problem is that while editors are super fast, the plugin/LSP integrations can really slow down the editing experience. While you can write the editor with GPU acceleration in Rust, the language servers will remain unchanged. Dealing with edge cases and concurrency is really difficult, even in Rust.
For example, if you activate auto complete, but there are multiple servers returning results with different response times. Do you wait for all of them to finish? If not, will you have results that jump around?
There were some new ideas a few (10+) years ago around how to visualize and navigate code, basically letting you edit through the program flow rather than by file. I was really keen on the idea but they only worked for Java, if I recall correctly. I'd love to see those ideas play out again with typescript, rust, etc.
Last time I tried zed it didn't have good git integration. I look at diffs and blame a lot and both vim and vscode have really great plugins.
Embedding media (the way a lot of markdown editors work) is one of the features I mentioned wanting on a new IDE wishlist. Preserving last seen arguments passed through a local debug session for future replays would also be handy.
The issue such things face is that they are very difficult to justify. If you say "I am going to improve the efficiency of the rendering process by 30%", no one will question what you're doing. The numbers are better than before, so it has clearly improved the software. But if you say "I'm going to implement images in comments", there are suddenly all sorts of questions. Will people use it? What if it degrades experience? What if it contributes to bloat? Etc. If you were to ask which of the features adds more value to the product, the answer is probably the second. But if you look at the feature on its own, it's much harder to justify doing work on the second than doing work on the first because there's no metric you are improving.
> How about a text editor which represents code as a syntax tree that is formatted as you type? Or one that has support for embedding multi-media content within source files? Or one with advanced program rewriting capabilities (in-lining functions, replacing struct members into getter methods, etc)
We have had these for decades, they are called IDEs
I've not seen many IDEs with the functionality I just listed. Most of the time it's just debugging support and code completion. The idea that most programmers have edited code in the way I just described for decades is patently absurd.
You mean one that formats code as you type, embeds multi-media within
source, rewrites class variables as getter methods? None of these could
be implemented in a way that even immature developers, those with 3-4
years of experience who go in for whizbangness, wouldn't immediately
deactivate.
Yes they totally could. I auto-format all my code and it works mostly without issue even in relatively complicated languages. Why would you turn of images in the source? A comment with a diagram would be useful. Rewriting class variables isn't something you can even turn off. It would just be an option in the right-click menu to refactor code. Everything I suggest is based to some extent on existing features. It is just a more complete implementation of them.
How about a text editor which represents code as a syntax tree that is formatted as you type? Or one that has support for embedding multi-media content within source files? Or one with advanced program rewriting capabilities (in-lining functions, replacing struct members into getter methods, etc)? These things would all change the a user's experience much more than replacing the CPU rendering with GPU rendering. A text editor is the window through which we interact with code. It is an immensely rich domain for experimentation, yet the best most come up with is "what if there was a 10ms smaller latency on keyboard input?"
I think the issue here is one of perspective. As programmers, we see the code. We tend to put more focus on the features that took us the longest to implement. But often, these are not visible or relevant to the user. We like to show off the 80% of the effort that gets 20% of the outcome rather than the 20% that yields 80%. I think there's also a measurability bias at play. It's easy to make the case that a faster thing is better than a slower thing, but harder to make the case for an interesting feature. One is measurable but the other is not.