as-cii

Hey! Zed co-founder here.

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!

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.

Hey elashri, Zed co-founder 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.

Hey fau, Zed founder here.

Apologies if that issue has taken a while to fix: next week is "quality week" at Zed and I am personally going to take a look at it again.

Thanks for the feedback!

Hey! Zed founder here.

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.

Curious to hear what you think!

Hey, Antonio here. Co-founder at Zed.

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.

[0]: https://github.com/zed-industries/extensions

[1]: https://github.com/zed-industries/zed/tree/main/extensions

[2]: https://github.com/zed-industries/zed/tree/main/crates/langu...

[3]: https://zed.dev/blog/language-extensions-part-1

Hey nottorp. Antonio here, author of the post.

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.

Thanks for the feedback!

Hey rob74! Antonio here, author of the post.

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.

Thanks, almostdigital!

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.

Hey xlii! This is Antonio, author of the post.

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.

Thanks for reading and commenting!