maxbrunsfeld

Yes

In the new layout, the project panel and git panel are just moved to the right side, so that the agent panel could be on the left, and you could still view both at the same time.

Curious about the failure to detect FS changes made outside of Zed. Are you on Linux?

Agreed, we should support this!

The Zed spirit is definitely to prefer a platform native solution.

You're right that we may be able to get rid of our WGSL implementation, and instead use the HLSL one via SPIR-V. But also, at some point we plan to port Zed to run in a web browser, and will likely build on WebGPU, where WGSL is the native shading language. Honestly, we don't change our graphics primitives that frequently, so the cost of having the three implementations going forward isn't that terrible. We definitely would not use MoltenVK on macOS, vs just using Metal directly.

Good point that we should publish a symbol server.

The fix shipped in Zed 0.185.12.

Isaac, that email that you sent to us (long after your internship ended) when Wasmtime first landed support for the WASM Component model was actually very helpful! We were considering going down the path of embedding V8 and doing JS extensions. I'm really glad we ended up going all in on Wasmtime and components; it's an awesome technology.

You can still include Text Threads as context in the inline assist prompt with @thread "name of thread", or using the `+` button. And it should suggest the active text thread for you, so it's one click. Let us know if that isn't working, we wanted to preserve the old workflow (very explicit context curation) for people who enjoyed previous assistant panel.

I believe this PR fixes the issue: https://github.com/zed-industries/zed/pull/30178.

Thanks for the information. We can reproduce this using Copilot Chat. We're fixing now. We'll let you know when the fix is out.

Yeah, we plan to revisit the collaboration features; it was painful but we decided we needed to pause work on it while we built out some more highly-requested functionality. We still have big plans for improving team collaboration!

Some things are just much faster in an editor.

I used `git add -p` until very recently (basically, until we built this feature in Zed). If you're using `add -p` and you notice a problem that you want to fix before committing, you need to go find that same bit of code in your editor, edit the code, then re-start your `add -p`. If you had chosen not to stage some preceding hunks, you need to skip over those again. Also, an editor can just render code much more readably than the git CLI can.

Just to clarify, you can run as many LSPs in a given file type as you want.

Common features like completions, diagnostics, and auto-formatting will multiplex to all of the LSPs.

Admittedly, there are certain features that currently only use one LSP: inlay hints and document highlights are examples. For which LSP features is multi-server support important to you? It shouldn't be too hard to generalize.

You can. This is fully supported.

There are extensions for scheme and racket: - https://zed.dev/extensions?query=scheme - https://zed.dev/extensions?query=racket

I had the same question. I would think that with rust’s Vec, no allocation would occur at steady state. Vec does not automatically resize when removing elements.

As a point of clarification, the script does not edit your zshrc file, it just prints a suggested edit that you may want to make to that file in order to add zed to your PATH.

If this happens with Zed 0.129 or later, could you open an issue? We had a problem at one point where there was a delay in macOS verifying our app’s code signature because we weren’t attaching the code signature correctly.

It has created a culture in which checking in enormous generates files is common.

You're not required to do that, and never have been. We're going to move the grammars away from checking the generated `parser.c` in, but early in the project, it was a pretty pragmatic solution, given that many consumers of the grammars weren't using a particular package registry like NPM or crates.io.

It abdicates common and important features in popular languages like significant whitespace to error-prone external scanners.

External scanners are the right tool for this. Nobody has proposed a better solution for this that actually works, and I don't think there is one, because every programming language with significant implements it differently.

The GLR algorithm sometimes fails inexplicably and is essentially impossible to debug (not sure if the bugs are in the algorithm or the implementation)

It sounds like you personally have had trouble with debugging a grammar you've tried to develop, but it solves a problem.

It bizarrely uses rust and node.

Tree-sitter isn't very coupled to node. We just shell out to a JS engine because we use JS (the most popular programming language, period) as a grammar DSL, rather than inventing our own language. Node is the most common one.

the generated c files are insanely (probably a consequence of the GLR algorithm)

No, it's not because of GLR. A lot of the reason for the C code size is that we want to generate nice, readable, multi-line C expressions to represent data structures like parse tables, rather than encoding it in some cryptic, unreadable way. Also, incremental parsing requires that a bit more data be present in the parse table than would be required for a batch-only parser. What really matters is the code size of the final binaries. The generated `.so` or `.wasm` files for a Python parser are 503k, and 465k, respectively. The wasm gzips down to 69k. I would love to make it smaller, but there are pretty good reasons why it occupies the size that it does, and it's currently pretty manageable.

It also uses (unless it's been updated in the last six months) a terrible algorithm for unicode lexing.

I'm not sure what you're referring to here. UTF8 and UTF16 are decoded into code points using standard routines from `libicu`.

Did you open an issue for the segfault you got, on the Tree-sitter repo or the repo for the particular parser you were using?

It's not really accurate to say that Tree-sitter segfaults constantly. The Tree-sitter CI performs randomized fuzz testing based on a bunch of popular grammars, randomly mutating entries from their test corpus. If you have a reproduction case for the segfault, it'd be useful to report.

Since you mention NPM, it sounds like you may be talking about a segfault that's specific to the Tree-sitter Node.js bindings, but it's hard to be sure.

The moment that you open Zed for the first time, you see a welcome screen that offers telemetry opt-out.

The editor will be open-source and cross-platform, but it takes time to build things.

Thanks for pointing this out. Our whole terms-of-service is just standard boilerplate provided by our lawyers, but this part doesn't really apply to Zed. Obviously, there's no "content moderation" for project code that you collaborate on with Zed.

We'll look into adjusting this to make it clearer that we don't do anything remotely concerning or invasive.

WebRTC

Right now, this is just used for the screen-sharing feature.

The binary is pretty big by itself

It is. One major reasons is that we're shipping a "fat binary" (x86_64 and arm64 build in a single file). We did this to simplify the download process for users, but now that the app is getting bigger, we should probably start shipping two separate DMGs, to reduce the download time. That would cut the binary size in half.

Our plan is for the core editor to be free and open-source.

We'll charge money for our backend service that powers collaboration in Zed. We have ambitious plans to improve the way that people work together on code. So far, on that front, we've been focused on real-time collaboration, but we have a lot of ideas for how we can improve asynchronous collaboration as well, by having discussions take place directly in the code editor.

No. It's written in Rust, with a custom UI framework. More details in this blog post: https://zed.dev/blog/videogame

Yeah, the plan is to open-source the editor itself before we release 1.0. We will probably keep some part of the collaboration system closed-source, so that we can build our business around that feature set.

We have some work to do to decide exactly what will be closed source and separate that out from the rest of the application code.

What forms of keyboard navigation are you missing? We try to make sure everything is controllable from the keyboard.

We went with CoreText on macOS because we wanted to make sure that text in Zed matched the look of other macOS apps. We'll probably end up using HarfBuzz for the Linux and Web versions, and possibly Windows too.

Yes, we do plan to open-source GPUI, as well as the Zed editor itself.

Right now, our plan is to keep certain collaborative features the editor as closed source, because we would like to build a business around those features. So before we open-source anything, we have to do some work to identify and cleanly separate those closed-source components.

I think that the paragraph that you quoted was in reference to Xi's decision to use CRDTs (and asynchronous communication) for exchanging data between different plugins running in the same instance of Xi. It isn't a comment about the use of CRDTs for collaborative editing, as Zed does.