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.

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.