I just want a fast programmable text editor with a native GUI and good defaults.
But that seems really tough to find, for some reason.
Zed is so close, but I’d much rather see a focus on the “programmable” part and let the AI and collaboration features emerge later out of rich extensibility (i.e. as plugins, perhaps even paid plugins) than have them built-in behind a sign-in and unknown future pricing model.
In the case of Zed it was always inevitable, a text editor doesn't raise >$10M in venture capital unless there's a plan to stuff it full of premium subscription features.
Warp Terminal is a similar story, >$50M in funding for a terminal emulator of all things...
> I just want a fast programmable text editor with a native GUI and good defaults.
It's called TextAdept. Much of it is itself built on its own Lua extensibility story, which runs on a fairly compact C core. Both native GUI and terminal versions, using the same user config (keybinds etc). Linux, Mac OS, Windows builds. LSP support built in. Plenty of community-produced extensions around (but of course not as vast a range as VSCode's VSX eco-system furnishes).
Is VSCode out for some reason? I don’t care for the defaults for some language plugins, but it seems easier to ship VSCode config than to build a whole editor.
I think the VSCode config is just JSON on disk and I believe you can install plugins on the CLI. You could probably have a bash or Python script do the setup pretty easily.
Edit: responded before coffee, missed the “native GUI”; please disregard
It doesn't mean your code is NOT being uploaded somewhere. They could add an easy switch to use the editor 'offline', not that they have to. I'll go back to Helix.
This means 100x more effort in the long run for a cross platform editor. Maybe if developers lived for 200 years, this could be possible. Will need to solve human ageing problem before the cross platform "native GUI" problem.
Native GUIs offer far better accessibility (TUIs are not screen-reader accessible, and neither is Emacs' GUI currently), hugely improved UI flexibility and consistent developer APIs (Emacs GUI is inconsistent across platforms and tricky to work with, every Neovim plugin reinvents ways to draw modals/text input because there's no consistent API), reduced redraw quirks, better performance, better debugging (as a Neovim plugin dev I don't want to spend time debugging user reports that relate to the user's choice of terminal emulator this week and not to Neovim or my plugin code).
If a motivated solo dev thought there might be at least 10,000 people who would pay 100 USD a year for a text editor with better extensibility and performance than VS Code and better defaults/richer GUI APIs than vim/Emacs, I can see why it might be tempting for them to try.
Using the same platform-specific graphics API the OS vendor builds their GUI apps with, ideally, but I'll also settle for "not a TUI, not a web application shipped as a desktop app, even if the OS vendor currently builds their GUI apps as web applications shipped as desktop apps".
A GUI that uses native controls and platform UI conventions with the native behavior expected on the given platform, or a near-indistinguishable equivalent of that.
There's two ways to make extensions to Zed, providing context for AI. In the post they show off making a Rust -> WASM based extension and also mention a server based model. There's also a third option -- Zed is open source. You don't have to use their auth, it just makes collaboration easy.
we call the latter a "Context Server", basically any process that communicates via JSON-RPC over stdio can do it. documentation for that is here: https://zed.dev/docs/assistant/context-servers
But that seems really tough to find, for some reason.
Zed is so close, but I’d much rather see a focus on the “programmable” part and let the AI and collaboration features emerge later out of rich extensibility (i.e. as plugins, perhaps even paid plugins) than have them built-in behind a sign-in and unknown future pricing model.