I interned at zed during the summer of 2022, when the editor was pre-alpha. Nathan, Max, Antonio are great guys and build software with care. I'm happy to see the editor receive the success it deserves, because the team has poured so much world-class engineering work into it.
I worked with Antonio on prototyping the extensions system[0]. In other words, Antonio got to stress test the pair programming collaboration tech while I ran around in a little corner of the zed codebase and asked a billion questions. While working on zed, Antonio taught me how to talk about code and make changes purposefully. I learned that the best solution is the one that shows the reader how it was derived. It was a great summer, as far as summers go!
I'm glad the editor is open source and that people are willing to pay for well-engineered AI integrations; I think originally, before AI had taken off, the business model for zed was something along the lines of a per-seat model for teams that used collaborative features. I still use zed daily and I hope the team can keep working on it for a long time.
[0]: Extensions were originally written in Lua, which didn't have the properties we wanted, so we moved to Wasm, which is fast + sandboxed + cross-language. After I left, it looks like Max and Marshall picked up the work and moved from the original serde+bincode ABI to Wasm interface types, which makes me happy: https://zed.dev/blog/zed-decoded-extensions. I have a blog post draft about the early history of Zed and how extensions with direct access to GPUI and CRDTs could turn Zed from a collaborative code editor into a full-blown collaborative application platform. The post needs a lot of work (and I should probably reach out to the team) before I publish it. And I have finals next week. Sigh. Some day!
I wish they would have stayed with the collaborative part a bit longer. Once the AI wave hit it feels abandoned with various bugs and hard to reproduce issues. I am a full time zed user converting from sublime only due to the collaborative features, but by now we don't even use the collaborative features anymore because it's unreliable (broken connections, sounds, overwriting changes, weird history/undo behavior), so will probably go back to sublime again. Note that all of us are sitting on fiber connections, so I don't believe the issues are network related.
I've been trying to be active, create issues, help in any way I can, but the focus on AI tells me Zed is no longer an editor for me.
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!
It's absolutely remarkable that these folks are writing this from scratch in Rust. That'll be a long-term killer feature for the editor.
Do you think GPL3 will serve as an impediment to their revenue or future venture fundraising? I assume not, since Cursor and Windsurf were forks of MIT-licensed VS Code. And both of them are entirely dependent on Microsoft's goodwill to continue developing VS Code in the open.
Tangentially, do you think this model of "tool" + "curated model aggregator" + "open source" would be useful for other, non-developer fields? Would an AI art tool with sculpting and drawing benefit from being open source? I've talked with VCs that love open developer tools and they hate on the idea of open creative tools for designers, illustrators, filmmakers, and other creatives. I don't quite get it, because Blender and Krita have millions of users. Comfy is kind of in that space, it's just not very user-friendly.
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.
Yes, Wasm components rock! I'm amazed to see how far you've taken Wasm and run with it. I'm at a new email address now, apologies if I've missed any mail. We should catch up sometime; I'll be in SF this summer, I might also visit a friend in Fort Collins, CO. (Throwing distance from Boulder :P)
Hey Isaac! I was intrigued by the way Zed added extensions, and I think it turned out great! I ended up taking that pattern of WASM, WIT, and Rust traits to add interactive hot reloading in a few projects. It feels like it has a strong future in gamedev where you could load and execute untrusted user mods without having all your players getting hacked left and right.
Thank you Brian! I miss tonari, I hope you're well. Game mods seem like a great fit for Wasm! I'm excited about Wasm GC, etc., because it means you can use e.g. a lightweight scripting language like Lua to sketch a mod, with the option of using something heavier if you need that performance.
Hey! I was reading your extensions code a lot. The backwards compatibility is done in a smart way. Several layers of wit and the editor makes the choice based on wasm headers which one to choose.
I learned something from that code, cool stuff!
One question: how do you handle cutting a new breaking change in wit? Does it take a lot of time to deal with all the boilerplate when you copy things around?
Thank you, I bring this up in every Zed thread on the internet, hopefully the devs will eventually fix it. Until they do, Zed is simply unusable on regular-DPI displays, at least in light mode. See these screenshots:
I think it's a combination of using a Zed theme with insufficiently high text contrast, missing subpixel font rendering in Zed, and possibly more gamma correction and less stem darkening than you're used to.
Zed defaults to a font weight a little thin for my taste, increase it and it will probably solve your issue. I don’t see anything really wrong with the first screenshot, might just be a matter of what you are used to.
I'm wildly guessing here, but I remember that at some point in time macos had (and maybe has) this feature enabled by default which artificially makes pseudo-bold font out of regular font. That's why some websites have very thin and unreadable fonts, because they were tested only on macos. Maybe it's the same issue here? Looks kinda similar.
Setting on macos was called "use font smoothing when available".
> The entire Zed code editor is open source under GPL version 3, and scratch-built in Rust all the way down to handcrafted GPU shaders and OS graphics API calls.
When I saw this, I immediately wondered what strange rendering bugs Zim might run into. This was before reading your comment.
In my opinion, this type of graphics work is not the core functionality of a text editor, same has been solved already in libraries. There is no reason to reinvent that wheel... Or if there is then please mention why.
Most likely there were no ready libraries when they started. Even now there are very few that can be called stable. And even then many of them are HTML based.
So if you are going to spend that much time developing GUI from scratch you might as well make it your own library and get full control.
shrink the zed window by one pixel horizontally and one pixel vertically. there's a video on that issue page which shows resizing making the font go in and out of focus, and that tells me that there's something dividing the window height and width by 2 and starting the font rendering there. if you divide by 2 and you get .5, you'll see the blurriness. if you make the window 1 pixel wider you won't get x.5 anymore, you'll get a whole number.
try it and see. i bet that helps/fixes at least some of you suffering from this.
Not sure if it's related, but I've built Zed from source to try on Windows (I haven't tried it on other platforms), and it does not look good sadly, it's also quite a bit "uncrisp" or something - I don't really have the words to describe.
Does your monitor have a nonstandard rgb pattern? If zed is trying to do its own subpixel rendering then getting the pattern wrong is going to mess up your results.
If you are using MacOS, unfortunately, your issue is that you are using a 1440p monitor, not an issue with any one program.
Apple has removed support for font rendering methods which make text on non-integer scaled screens look sharper. As a result, if you want to use your screen without blurry text, you have to use 1080p (1x), 4k (2x 1080p), 5k (2x 1440p) or 6k screens (or any other screens where integer scaling looks ok).
To see the difference, try connecting a Windows/Linux machine to your monitor and comparing how text looks compared to the same screen with a MacOS device.
This comment is incorrect, I have tried the editor on both MacOS and Linux, and texts looks like crap on both if you're using your screen at its native resolution. The difference is easily visible in screenshots.
native resolution on any monitor should work fine on MacOS.
using pixel fonts on any non-integer multiplier of the native resolution will always result in horrible font rendering, I don't care what OS you're on.
I use MacOS on all kinds of displays as I move throughout the day, some of them are 1x, some are 2x, and some are somewhere in between. using a vector font in Zed looks fine on all of them. It did not look fine when I used a pixel font that I created for myself, but that's how pixel fonts work, not the fault of MacOS.
1440p monitor would probably be why the text is blurry - there simply isn't enough pixels to make things smooth without resorting to special hacks to improve LowDPI text rendering, which with more and more displays being HiDPI many don't bother doing.
I am amazed people consider 1440p low resolution. My knee-jerk reaction was to assume you were sarcastic. I use a monitor of roughly that many lines of pixels and have never had observed blurry text in the tools I use (and I use fairly small fonts).
1440p is high enough for anything depending on screen size.
If they're running everything on the GPU then their SDF text rendering needs more work to be resolution independent. I'm assuming they use SDFs, or some variant of that.
Really, the screen isn't the issue given that on other editors OP says it is fine.
I was using Zed up until a few months ago. I got fed up with the entire AI panel being an editable area, so sometimes I ended up clobbering it. I switched to Cursor, but now I don't "trust" the the editor and its undo stack, I've lost code as a result of it, particularly when you're in mid-review of an agentic edit, but decide to edit the edit. The undo/redo gets difficult to track, I wish there was some heirarchical tree view of history.
The restore checkpoint/redo is too linear for my lizard brain. Am I wrong to want a tree-based agentic IDE? Why has nobody built it?
Interesting. I actually like the editable format of the chat interface because it allows fixing small stuff on the fly (instead of having to talk about it with the model) and de-cluttering the chat after a few back and forths make it a mess (instead of having to start anew), which makes the context window smaller and less confusing to the model, esp for local ones. Also, the editable form makes more sense to me, and it feels more natural and simple to interact with an LLM assistant with it.
Been using cline and their snapshot/rewind/remove context (even out-of-order) features are really shining especially with larger projects and larger features+changes becoming more commonplace with stronger LLMs.
I would recommend you check it out if you've been frustrated by the other options out there - I've been very happy with it. I'm fairly sure you can't have git-like dag trees, nor do I think that would be particularly useful for AI based workflow - you'd have to delegate rebasing and merge conflict resolution to the agent itself... lots of potential for disaster there, at least for now.
omg. "the entire AI panel being an editable area" is the KILLER feature for me!
I have complete control, use my vim keys, switch models at will and life is awesome.
What I don't like in the last update is that they removed the multi-tabs in the assistant. Previously I could have multiple conversations going and switch easily, but now I can only do one thing at a time :(
Haven't tried the assistant2 much, mostly because I'm so comfy with my current setup
You will not catch me using the words "agentic IDE" to describe what I'm doing because its primary purpose isn't to be used by AI any more than the primary purpose of a car is to drive itself.
But yes, what I am doing is creating an IDE where the primary integration surface for humans, scripts, and AIs is not the 2D text buffer, but the embedded tree structure of the code. Zed almost gets there and it's maddening to me that they don't embrace it fully. I think once I show them what the stakes of the game are they have the engineering talent to catch up.
The main reason it hasn't been done is that we're still all basically writing code on paper. All of the most modern tools that people are using, they're still basically just digitizations of punchcard programming. If you dig down through all the layers of abstractions at the very bottom is line and column, that telltale hint of paper's two-dimensionality. And because line and column get baked into every integration surface, the limitations of IDEs are the limitations of paper. When you frame the task of programming as "write a huge amount of text out on paper" it's no wonder that people turn to LLMs to do it.
For the integration layer using the tree as the primary means you get to stop worrying about a valid tree layer blinking into and out of existence constantly, which is conceptually what happens when someone types code syntax in left to right. They put an opening brace in, then later a closing brace. In between a valid tree representation has ceased to exist.
Representing undo/redo history as a tree is quite different from representing the code structure as a tree. On the one hand I'm surprised no one seems to care that a response has nothing to do with the question... on the other hand, these AI tooling threads are always full of people talking right past each other and being very excited about it, so I guess it fits.
I've very interested in this, and completely agree we are still trying to evolve the horse carriage without realizing we can move away from it.
How can I follow up on what you're building? Would you be open to having a chat? I've found your github, but let me know how if there's a better way to contact you.
Meanwhile I'm checking Helix editor every 6 month to see if authors became any less hostile to the idea of thinking about considering of starting thinking about potentially adding copilot support.
Why should an open source editor support some single commercial product API in their core? Why copilot and not another product?
It's completely reasonable to me that this should be a third party plugin or that they should wait for some standard that supports many products.
As @adriangalilea recently aptly wrote in Helix's 2nd-longest discussion thread (#4037):
> For the nth time, it's about enabling inline suggestions and letting anything, either LSP or Extensions use it, then you don't have to guess what the coolest LLM is, you just have a generic useful interface for LLM's or anything else to use.
An argument I would agree with is that it's unreasonable to expect Helix's maintainers to volunteer their time toward building and maintaining functionality they don't personally care about.
It's not about it being locked to a commercial product — whatever they built would be provider-agnostic. My understanding is the decision is more about not wanting to build things into core that are evolving so quickly and not wanting to rely on experimental LSP features (though I think inline completions are becoming standard soon[1]). Zed itself is perfect evidence of that -- they built an AI integration and then basically had to throw it away and rebuild it because the consensus best practice design changed. The Helix maintainers don't have time for that kind of churn and aren't trying to keep up with the hype cycle. When the plugin system is ready people will be able to choose their preferred implementation, and maybe eventually some aspects of it will make it into core.
Interestingly enough, this is exactly why I've started using Zed – while simultaneously eagerly waiting for Helix PR #8675 (Steel plugin system) to get merged. It's not far off, but then again, many Helix PRs seem that way, only to stay in limbo for months if not years.
These last two months I've been trialing both Neovim and Zed alongside Helix. I know I should probably just use Neovim since, once set up properly, it can do anything and everything. But configuring it has brought little joy. And once set up to do the same as Helix out of the box, it's noticeably slower.
Zed is the first editor I've tried that actually feels as fast as Helix while also offering AI tooling. I like how integrated everything is. The inline assistant uses context from the chat assistant. Code blocks are easy to copy from the chat panel to a buffer. The changes made by the coding agent can be individually reviewed and accepted or rejected. It's a lot of small details done right that add up to a tool that I'm genuinely becoming confident about using.
Also, there's a Helix keymap, although it doesn't seem as complete as the Vim keymap, which is what I've been using.
Still, I hope there will come a time when Helix users can have more than just Helix + Aider, because I prefer my editor inside a terminal (Helix) rather than my terminal inside an editor (Zed).
The authors don’t seem hostile at all. They’re firmly against putting work into a feature they don’t care for but welcome pro-AI users to make it happen. For some reason the latter group hasn’t seemed to accomplish it.
Unless something's changed, every AI-backed language server I've tried in Helix suffers from the same limitation when it comes to completions: Suggestions aren't shown until the last language server has responded or timed-out. Your slowest language server determines how long you'll be waiting.
The only project I know of that recognizes this is https://github.com/SilasMarvin/lsp-ai, which pivoted away from completions to chat interactions via code actions.
I feel like an LSP is very insufficient for the ideal UX of AI integrations. LSP would be fine for AI autocompletes of course, but i think we want a custom UX that we don't quite yet know. Eg what Zed offers here seems useful. I also really like what Claude Code does.
I don't know the LSP spec well enough to know if these sort of complex interactions would work with it, but it seems super out of scope for it imo.
This rings so true for me! Helix is beautiful and works fantastic, I'm pretty happy not having AI integrated into my editor so Helix is basically exactly as I want without any extras I don't!
This seems more in scope of those same people who want to make their editor into an IDE. And just like most other things, the editor is a poor integration point for AI. The shell and inter-process communications are the gold standard for integration and are where the best integrations emerging from. Things that work with your editor instead of trying to replace it. Aider being the best example I've seen so far... though I'd love to hear about others.
I can understand that, and it's great if it fits your needs. It's annoying when apps that just have to do one thing and do it well instead are focusing on hype features. My recent rant is about Warp terminal that has a "different font size for different tabs" issue open for years, but silently integrated all sorts of AI into the terminal.
And yet, it's hard to ignore the fact that coding practices are undergoing a one-in-a-generation shift, and experienced programmers are benefiting most from it. Many of us had to ditch the comfort of terminal editors and switch to Microsoft's VSCode clones just to have these new incredible powers and productivity boosts.
Having AI code assistants built into the fast terminal editor sounds like a dream. And editors like Helix could totally deliver here if the authors were a bit more open to the idea.
Zed is exactly how software should be made. Granted, I don't agree with all of their UX decisions (i think the AI panel is really bad compared to Cursor's), but good lord is the thing fast. These guys are the real deal. They built a rendering system (GPUI) in Rust before building Zed on top of it, and so it is one of the fastest (if not the fastest) pieces of software that resides on my computer. I can't wait until GPUI becomes a bit more mature/stable so I can build on top of it, because the other Rust GUI libraries/frameworks aren't great.
> I can't wait until GPUI becomes a bit more mature/stable so I can build on top of it
Man, so true. I tried this out a while back and it was pretty miserable to find docs, apis, etc.
IIRC they even practice a lot of bulk reexports and glob imports and so it was super difficult to find where the hell things come from, and thus find docs/source to understand how to use something or achieve something.
Super frustrating because the UI of Zed was so damn good. I wanted to replicate hah.
part of me wants to dedicate time to making something with it and then creating examples/PRs -- but it's too unstable given how fast they're moving for now IMO. if anyone from Zed team can chime in and confirm, that'd be awesome.
i have and it's more of the same (unless i'm missing something). the fact that the entire thing is editable is weird to me. i really think they should just clone cursor's in this one case because they really nailed the UX with the checkpoint restoration
edit: yes i missed something. i see the new feature. hell yeah!
I’ve been using Zed a few months on my fedora laptop (thinkpad x230) and haven’t had any performance issues. Definitely faster than any other graphical editor I’ve used. Perhaps a driver issue would be slowing it down?
I'm under Debian and i3wm/X11, sometimes it does some stuff that blocks input for a while so I can't drive the window manager until its done.
At least it did a month or so ago, and at that time I couldn't figure out a practical use for the LLM-integration either so I kind of just went back to dumb old vim and IDEA Ultimate.
When its fast its pretty snappy though. I recently put revisiting emacs on my todo-list, should add taking Zed out for another round as well.
That sounds a lot like a CPU fallback of the rendering that should otherwise happen on the GPU. Isn't there any logs that could suggest that this is the case?
Edit: I just saw your edit to your reply here[1] and that's indeed what's happening. Now the question is “why does that happen?”.
there's basically zero documentation for Iced as it stands. They even wrote that if you're not a great Rust dev, you're going to have a bad time and that all docs are basically "read the code" until their book is written. I'm glad System76 is able to build using Iced, but you need a great manual for a tool to be considered mature and useful.
IMO Slint is milestones ahead and better. They've even built out solid extensions for using their UI DSL, and they have pages and pages of docs. Of course everything has tradeoffs, and their licensing is funky to me.
> I can't wait until GPUI becomes a bit more mature/stable so I can build on top of it
I wouldn’t hold my breath. GPUI is built specifically for Zed. It is in its monorepo without separate releases and lots of breaking changes all the time. It is pretty tailored to making a text editor rather than being a reusable GUI framework.
Firefox rendering is based on WebRender, which runs on OpenGL. The internals of WebRender are similar to gpui but with significantly more stuff to cover the landscape of CSS.
Went from Atom, to VSC, to Vim and finally to Zed. Never felt more at home. Highly recommend giving it a try.
AFAIK there is overlap between Atoms and Zeds developers. They built Electron to built Atom. For Zed they built gpui, which renders the UI on the GPU for better performance. In case you are looking for an interesting candidate for building multi platform GUIs in rust, you can try gpui yourself.
People have been using editors that look comparable for decades that dont need fancy GPU rendering to be fast and responsive. What is happening that stuff like that is necessary now?
GPU rendering in some form or another (mostly just bitblitting characters, I guess) has also been common for decades. Classic hardware text mode is basically just that. Also, display densities and sizes have gone up (for some of us).
The first time I used Zed, I really noticed and appreciated the very low latency between a keypress and visual result. It created a great sense of “connection” to the experience. (I’ve previously used VS Code, Emacs, Sublime Text, JetBrains, and others)
I generally use Neovim, but Zed was the first code editor that made me go, "Wow, I can see myself actually using this." My only gripe is the "Sign In" button at the top that I can't seem to remove.
But apropos TFA, it's nice to see that telemetry is opt-in, not opt-out.
Yeah. I've been using vim since the 90's. A bit of emacs here and there, and more recently some helix too. Zed was the first GUI editor that took me over. I've always hated VSCode, but Zed is so fast and its UI just clicks on me that I've been using it as my main editor for months now.
Subscribed to their paid plan just to keep the lights on and hoping it will get even better in the future.
Not OP, but the Sign In button is for GitHub on Zed. Which conflicts with GitHub sign in for any of the other AI agents, so you have to pick only one (the others will time out and do nothing after the first).
On work machines I use the corporate Copilot login, so I just have a permanent Sign In button in the upper right that doesn't function and can't be hidden.
Also I don't want to pay with my private data from some of my systems. So I don't ever want to sign in on those systems and just have a useless button sitting there.
It’s funny that they lead with AI tools. I love zed because it’s fast, customizable, has a clean interface and it’s easy to pair program. The LLM bit is just an annoying thing I shut off because imo I’m too junior at the moment to use LLMs
I was interested in zed as I was looking for a performant VSCode replacement, but its inability to fully remove AI integration and disable the prominent sign-in button made me lose any interest. Judging by the project’s response or lack of it on these topics, I am worried about adopting zed in my workflows.
Its a small button in the top right corner. Very oit of the way unless interacted with. I use zed because its faster and cleaner than vscode. I dont want AI in my editor.
Readit News
I worked with Antonio on prototyping the extensions system[0]. In other words, Antonio got to stress test the pair programming collaboration tech while I ran around in a little corner of the zed codebase and asked a billion questions. While working on zed, Antonio taught me how to talk about code and make changes purposefully. I learned that the best solution is the one that shows the reader how it was derived. It was a great summer, as far as summers go!
I'm glad the editor is open source and that people are willing to pay for well-engineered AI integrations; I think originally, before AI had taken off, the business model for zed was something along the lines of a per-seat model for teams that used collaborative features. I still use zed daily and I hope the team can keep working on it for a long time.
[0]: Extensions were originally written in Lua, which didn't have the properties we wanted, so we moved to Wasm, which is fast + sandboxed + cross-language. After I left, it looks like Max and Marshall picked up the work and moved from the original serde+bincode ABI to Wasm interface types, which makes me happy: https://zed.dev/blog/zed-decoded-extensions. I have a blog post draft about the early history of Zed and how extensions with direct access to GPUI and CRDTs could turn Zed from a collaborative code editor into a full-blown collaborative application platform. The post needs a lot of work (and I should probably reach out to the team) before I publish it. And I have finals next week. Sigh. Some day!
I've been trying to be active, create issues, help in any way I can, but the focus on AI tells me Zed is no longer an editor for me.
Do you think GPL3 will serve as an impediment to their revenue or future venture fundraising? I assume not, since Cursor and Windsurf were forks of MIT-licensed VS Code. And both of them are entirely dependent on Microsoft's goodwill to continue developing VS Code in the open.
Tangentially, do you think this model of "tool" + "curated model aggregator" + "open source" would be useful for other, non-developer fields? Would an AI art tool with sculpting and drawing benefit from being open source? I've talked with VCs that love open developer tools and they hate on the idea of open creative tools for designers, illustrators, filmmakers, and other creatives. I don't quite get it, because Blender and Krita have millions of users. Comfy is kind of in that space, it's just not very user-friendly.
Deleted Comment
Good luck on finals!
I learned something from that code, cool stuff!
One question: how do you handle cutting a new breaking change in wit? Does it take a lot of time to deal with all the boilerplate when you copy things around?
I check back on the GitHub issue every few months and it just has more votes and more supportive comments, but no acknowledgement.
Hopefully someone can rescue us from the sluggish VS Code.
https://github.com/zed-industries/zed/issues/7992
I have a 1440p monitor and seeing this issue.
Example Zed screenshot, using "Ayu Light": https://i.ibb.co/Nr8SjvR/Screenshot-from-2024-07-28-13-11-10...
Same code in VS Code: https://i.ibb.co/YZfPXvZ/Screenshot-from-2024-07-28-13-13-41...
Setting on macos was called "use font smoothing when available".
In my opinion, this type of graphics work is not the core functionality of a text editor, same has been solved already in libraries. There is no reason to reinvent that wheel... Or if there is then please mention why.
In a world full of electron based apps, I appreciate anyone who dares to do things differently.
try it and see. i bet that helps/fixes at least some of you suffering from this.
I have the same issue with macOS in general, and I don't understand how anyone can use it on a normal DPI monitor.
I'm guessing zed implemented their own text rendering without either hinting or subpixel rendering or both.
https://github.com/waydabber/BetterDisplay
(Or are you using it in vertical orientation?)
It looks like the relevant work needs to be done upstream.
I don't know the internals of Zed well, but it seems entirely plausible they're doing text rendering from scratch.
Apple has removed support for font rendering methods which make text on non-integer scaled screens look sharper. As a result, if you want to use your screen without blurry text, you have to use 1080p (1x), 4k (2x 1080p), 5k (2x 1440p) or 6k screens (or any other screens where integer scaling looks ok).
To see the difference, try connecting a Windows/Linux machine to your monitor and comparing how text looks compared to the same screen with a MacOS device.
Example Zed screenshot, using "Ayu Light": https://i.ibb.co/Nr8SjvR/Screenshot-from-2024-07-28-13-11-10...
Same code in VS Code: https://i.ibb.co/YZfPXvZ/Screenshot-from-2024-07-28-13-13-41...
using pixel fonts on any non-integer multiplier of the native resolution will always result in horrible font rendering, I don't care what OS you're on.
I use MacOS on all kinds of displays as I move throughout the day, some of them are 1x, some are 2x, and some are somewhere in between. using a vector font in Zed looks fine on all of them. It did not look fine when I used a pixel font that I created for myself, but that's how pixel fonts work, not the fault of MacOS.
Apparently all editors bothered doing, except Zed.
From the Issue:
> Zed looks great on my MacBook screen, but looks bad when I dock to my 1080p monitor. No other editor has that problem for some reason.
If they're running everything on the GPU then their SDF text rendering needs more work to be resolution independent. I'm assuming they use SDFs, or some variant of that.
Really, the screen isn't the issue given that on other editors OP says it is fine.
Knuth would be angry reading this :)
The restore checkpoint/redo is too linear for my lizard brain. Am I wrong to want a tree-based agentic IDE? Why has nobody built it?
They fixed that with the new agent panel, which now works more like the other AI sidebars.
I was (mildly) annoyed by that too. The new UI still has rough edges but I like the change.
Vote/read-up here for the feature on Zed: https://github.com/zed-industries/zed/issues/17455
And here on VSCode: https://github.com/microsoft/vscode/issues/20889
I would recommend you check it out if you've been frustrated by the other options out there - I've been very happy with it. I'm fairly sure you can't have git-like dag trees, nor do I think that would be particularly useful for AI based workflow - you'd have to delegate rebasing and merge conflict resolution to the agent itself... lots of potential for disaster there, at least for now.
What I don't like in the last update is that they removed the multi-tabs in the assistant. Previously I could have multiple conversations going and switch easily, but now I can only do one thing at a time :(
Haven't tried the assistant2 much, mostly because I'm so comfy with my current setup
You will not catch me using the words "agentic IDE" to describe what I'm doing because its primary purpose isn't to be used by AI any more than the primary purpose of a car is to drive itself.
But yes, what I am doing is creating an IDE where the primary integration surface for humans, scripts, and AIs is not the 2D text buffer, but the embedded tree structure of the code. Zed almost gets there and it's maddening to me that they don't embrace it fully. I think once I show them what the stakes of the game are they have the engineering talent to catch up.
The main reason it hasn't been done is that we're still all basically writing code on paper. All of the most modern tools that people are using, they're still basically just digitizations of punchcard programming. If you dig down through all the layers of abstractions at the very bottom is line and column, that telltale hint of paper's two-dimensionality. And because line and column get baked into every integration surface, the limitations of IDEs are the limitations of paper. When you frame the task of programming as "write a huge amount of text out on paper" it's no wonder that people turn to LLMs to do it.
For the integration layer using the tree as the primary means you get to stop worrying about a valid tree layer blinking into and out of existence constantly, which is conceptually what happens when someone types code syntax in left to right. They put an opening brace in, then later a closing brace. In between a valid tree representation has ceased to exist.
How can I follow up on what you're building? Would you be open to having a chat? I've found your github, but let me know how if there's a better way to contact you.
https://github.com/helix-editor/helix/discussions/4037
> For the nth time, it's about enabling inline suggestions and letting anything, either LSP or Extensions use it, then you don't have to guess what the coolest LLM is, you just have a generic useful interface for LLM's or anything else to use.
An argument I would agree with is that it's unreasonable to expect Helix's maintainers to volunteer their time toward building and maintaining functionality they don't personally care about.
[1]: https://microsoft.github.io/language-server-protocol/specifi...
Deleted Comment
These last two months I've been trialing both Neovim and Zed alongside Helix. I know I should probably just use Neovim since, once set up properly, it can do anything and everything. But configuring it has brought little joy. And once set up to do the same as Helix out of the box, it's noticeably slower.
Zed is the first editor I've tried that actually feels as fast as Helix while also offering AI tooling. I like how integrated everything is. The inline assistant uses context from the chat assistant. Code blocks are easy to copy from the chat panel to a buffer. The changes made by the coding agent can be individually reviewed and accepted or rejected. It's a lot of small details done right that add up to a tool that I'm genuinely becoming confident about using.
Also, there's a Helix keymap, although it doesn't seem as complete as the Vim keymap, which is what I've been using.
Still, I hope there will come a time when Helix users can have more than just Helix + Aider, because I prefer my editor inside a terminal (Helix) rather than my terminal inside an editor (Zed).
https://github.com/helix-editor/helix/pull/8675
Also, the Helix way, thus far, has been to build a LSP for all the things, so I guess you'd make a copilot LSP (I be there already is one).
The only project I know of that recognizes this is https://github.com/SilasMarvin/lsp-ai, which pivoted away from completions to chat interactions via code actions.
I don't know the LSP spec well enough to know if these sort of complex interactions would work with it, but it seems super out of scope for it imo.
And yet, it's hard to ignore the fact that coding practices are undergoing a one-in-a-generation shift, and experienced programmers are benefiting most from it. Many of us had to ditch the comfort of terminal editors and switch to Microsoft's VSCode clones just to have these new incredible powers and productivity boosts.
Having AI code assistants built into the fast terminal editor sounds like a dream. And editors like Helix could totally deliver here if the authors were a bit more open to the idea.
edit: they updated the AI panel! looking good!
Man, so true. I tried this out a while back and it was pretty miserable to find docs, apis, etc.
IIRC they even practice a lot of bulk reexports and glob imports and so it was super difficult to find where the hell things come from, and thus find docs/source to understand how to use something or achieve something.
Super frustrating because the UI of Zed was so damn good. I wanted to replicate hah.
Have you had a chance to try the new panel? (The OP is announcing its launch today!)
The annoncement is about it reaching prod release, but they emailed people to try it out in the preview version.
edit: yes i missed something. i see the new feature. hell yeah!
I'm on PopOS and the issue ended up being DRI_PRIME.
Might be worth trying `DRI_PRIME=0 zed`.
At least it did a month or so ago, and at that time I couldn't figure out a practical use for the LLM-integration either so I kind of just went back to dumb old vim and IDEA Ultimate.
When its fast its pretty snappy though. I recently put revisiting emacs on my todo-list, should add taking Zed out for another round as well.
Edit: I just saw your edit to your reply here[1] and that's indeed what's happening. Now the question is “why does that happen?”.
[1]
Dead Comment
Iced, being used by System76's COSMIC EPOCH, is not great in what regards? Serious question.
IMO Slint is milestones ahead and better. They've even built out solid extensions for using their UI DSL, and they have pages and pages of docs. Of course everything has tradeoffs, and their licensing is funky to me.
I wouldn’t hold my breath. GPUI is built specifically for Zed. It is in its monorepo without separate releases and lots of breaking changes all the time. It is pretty tailored to making a text editor rather than being a reusable GUI framework.
i think there's some desire from within zed to making this a real thing for others to reuse.
Waiting for Robius / Makepad to mature a bit more. Looks very promising.
Deleted Comment
Went from Atom, to VSC, to Vim and finally to Zed. Never felt more at home. Highly recommend giving it a try.
AFAIK there is overlap between Atoms and Zeds developers. They built Electron to built Atom. For Zed they built gpui, which renders the UI on the GPU for better performance. In case you are looking for an interesting candidate for building multi platform GUIs in rust, you can try gpui yourself.
But apropos TFA, it's nice to see that telemetry is opt-in, not opt-out.
Subscribed to their paid plan just to keep the lights on and hoping it will get even better in the future.
It's open source, builds extremely well out of the box, and the UI is declarative.
Also I don't want to pay with my private data from some of my systems. So I don't ever want to sign in on those systems and just have a useless button sitting there.
One way you could use LLMs w/o inducing brain mush would be for code or design reviews, testability, etc.
If you see codebases you like, stash them away for AI explanation later.
https://github.com/zed-industries/zed/issues/12325
https://github.com/zed-industries/zed/issues/6756