We actually stream edits and apply them incrementally as the LLM produces them.
Sometimes we've observed the architect model (what drives the agentic loop) decide to rewrite a whole file when certain edits fail for various reasons.
It would be great if you could press the thumbs-down button at the end of the thread in Zed so we can investigate what might be happening here!
There currently is no official way of configuring Zed to use Ollama for edit prediction, but I would love to accept a pull request that implements it!
It should be relatively straightforward and we're happy to accept contributions here: this has been something I wanted to experiment with for a while but didn't get around to for the launch.
Would be a massive win that's fairly narrow in scope. More generally, being able to send arbitrary LSP commands to the server and see the response, even if it's just a text dump, would be super useful.
Love the project! I would say the only thing stopping me from moving over full time is a Git porcelain, but I'm sure you guys know that. Keep up the great work!
We totally agree with this and that's why Zed will switch the keybinding for accepting an edit prediction to `alt-tab` when the cursor is in the leading whitespace of a line. This way you can keep using `tab` for indenting in that situation.
Also, when there's both an edit prediction and and LSP completion, Zed switches the keybinding to `alt-tab` to prevent the conflict with accepting an LSP completion.
Sorry, I assumed macOS: but you're right! For Linux (and Windows, once we ship support for it) the keybinding is alt-l to avoid conflicting with tab switching.
Ohhh, is that why I keep pressing tab and it doesn't accept the prediction lately? I thought it was a bug. It feels weird for tab to double-indent when it could be accepting a prediction - I wonder if alt-tab to do a manual indent rather than accept the current prediction might be preferable?
Edit - On the other hand, a related issue is that if the prediction itself starts with whitespace, in that case it would be good if tab just indents like normal; otherwise you can't indent without accepting the prediction.
Sorry that we haven't replied to that GitHub issue yet. We try our best to listen to the community (here, on GitHub, on Discord, ...), but we're a small team and, admittedly, it's tricky to keep up with everything.
I agree that we should ask users for consent before downloading language servers (and other executables).
For everybody who's come across the ticket here or on Reddit and hasn't worked with the Zed codebase yet, let me provide some context on how language support is implemented.
In Zed, we have three ways of supporting a language (and its language servers):
1. Extensions that users can install from the `zed-extensions` repository [0]
2. Pre-bundled extensions that ship with the Zed binary, but still need to be installed [1]
3. Built-in language support [2].
For (2) and (3), the code is owned by the Zed team and we make a conscious effort to review contributions from the community in that area.
That code can automatically download language servers, but we try to vet which exact scripts/binaries are downloaded from where. For example: we heavily use rust-analyzer ourselves and keep up to date with its releases, the Go language server `gopls` is downloaded from the Go team using the official `go` tooling, the ESLint language server comes from Microsoft, etc.
For the longest time, we only had built-in language support (3). A couple of months ago, we shipped extensions for Zed (point 1 and 2 above, parts of it described in [3]). The goal was for built-in language support (3) to gradually move to pre-bundled extensions (2) so that users had the ability to choose which ones to install. We did make some progress, but we haven't ported all languages yet.
We're a small team and can only do so many things at once. So after investing quite a bit of time into extensions, we chose to pause that work and invest into other areas for a while (porting Zed to Linux, for example). Once those areas are in a better state, we plan to come back to extensions, build them out some more, and port the remaining languages.
So, TL;DR: we hear you loud and clear. We try to vet things that are currently installed automatically. But we agree that we should ask users whether they want to install arbitrary binaries on their computer. We also plan to transition all language support to manually-installed extensions once we finish other projects.
It's a new product, which is clearly seeing quick changes every week, so hopeful you'll get to this one soon. The internet will always be extreme around any issue, and make it seem like the end of the world, to those folks, maybe try zed again later? It's still a good editor to keep in mind.
Although one minor thing about this, getting users accustomed to this flow and then later asking for consent might also raise issues, like this one, just with a more "Zed now prompting for every little thing" in future. So might want to keep that in mind.
Loving zed for go development (especially with a decent suite of Vim bindings), just haven't been able to use things like Flutter , due to lack of debug support, which VSCode does quite well (albeit crashes a bunch).
I think some middle ground might be including an extension lock file that gets committed to the repo. For internal projects, users will get auto configured by trusting the other internal users that setup the repo.
For external projects, users need to trust the project they're pulling down anyway since it's arbitrary code.
That would also help mitigate the risk of supply chain attacks (since versions are pinned and ideally verify package integrity)
this answer makes things even worse. "we are a small team so its ok for us to expose your pc to risks".
If you dont have the bandwidth to do things securely dont do them at all.you are asking the devs to wait until you have time to return to it to plug the holes you have opened because you needed a bulletpoint for your release.
and this is not just a lack of time, its your attitude in regard to the devs, see also the optout telemetry for another example of total lack of respect for privacy.
Zed and GPUI use energy very judiciously and only perform updates when needed. The idea is that we can render the whole application within ~8ms, and that shows everywhere: from typing a letter to scrolling up and down in a buffer. However, if the editor is sitting there idle, we won't waste precious CPU cycles.
Yeah, might want to edit the title a bit. Or not, considering these concepts are getting lost.
I mean, the win16 api from ages ago had support for invalidating specific screen regions etc. It probably got lost somewhere in the transition to javascript...
Zed is not constrained to use fixed-width fonts and supports all kinds of fonts, monospaced and variable-spaced alike (ligatures and contextual alternates included). Even though we use a glyph atlas, we rely on CoreText for shaping and rasterization (rendering sub pixel variants as well). In practice, this means that text is indistinguishable from a piece of text rendered by the operating system.
After our past experience with Atom, getting the plugin system right is a top priority for the editor.
The thought of cross compatibility with VSCode plugins definitely crossed our mind and it's not out of the question, although our current plan is to initially support plugins using WASM.
You're right that rendering is only part of the story. To stay within the ~8ms frame budget, however, every little bit counts. Maintaining application state, layout, painting, and finally pushing pixels to screen, all need to be as performant as they can be.
For layout specifically we're using an approach inspired by Flutter, which lets us avoid complex algorithms but still have a lot of flexibility in the way elements can be positioned and produce a rich graphical experience.
I don't have experience with Flutter, but based on quick glance they're using widgeting and, what I found quite important - ability to develop GUI outside of the application. Something that I think libraries like egui are missing (and which is easily obtainable with Tauri/Dioxus).
Rebuilding whole app to ensure that some box doesn't get cut off ruins development experience, especially for big apps.
Kudos to you guys, I hope you'll make Zed extensible, so that instead of writing my own editor I can use yours ;-)
We actually stream edits and apply them incrementally as the LLM produces them.
Sometimes we've observed the architect model (what drives the agentic loop) decide to rewrite a whole file when certain edits fail for various reasons.
It would be great if you could press the thumbs-down button at the end of the thread in Zed so we can investigate what might be happening here!