I'm very happy to see work on the debugger. This is the main feature preventing me from switching full time to zed.
Unfortunately, "here" is not accurate. Not having a watch window, a stack trace view, and no mention of data breakpoints in the announcement still keeps the "beta" tag. I know those features will arrive eventually, but what is described is definitely not sufficient for 97% of my debugging sessions.
I would also have liked to see more in the announcement of multiple simultaneous debug sessions, and on how multithreaded debugging is planned. There are really cool things that can be done with multithreaded debugging further down the line that I'd be interesting in hearing about (like how RemedyBG has a DAW-like UI for freezing certain threads, or hitting one button to "solo" a thread and freeze all others).
happy-dude · 27m ago
The blog post mentions[1] that advanced views are in development. This initial release and announcement focuses on the underlying foundation they're building upon.
> New views: While we support all the fundamental views, we're planning on adding more advanced views such as a watch list, memory view, disassembly view, and a stack trace view
I agree but at the rate the Zed team is working at, we're not far off!
laserbeam · 26m ago
Oh yeah, of course :). My argument is they're just premature in declaring readiness.
odie5533 · 50m ago
100% of my debug sessions are with plain breakpoints and stepping. So it's here for me!
aequitas · 2h ago
I have to try out the debugger yet. However I share your sentiment but for the Git feature. The basics are there but it is just not complete yet to fully replace my current git workflow. Hope they keep focus on that as well.
koito17 · 1h ago
Nothing has been able to replace Magit for me, yet. Having a Zed UI for Git like Magit is my dream feature request.
With that said, Zed has effectively replaced all of Emacs for me, besides Magit. Additionally, typing in other editors feels noticeably higher latency than Zed :)
I've been daily driving Zed for almost a year now -- works best on TypeScript, Rust, and Go projects, in my opinion.
There's just so much functionality Zed has to build out to compete with modern editors (agentic coding, collaboration, debugging, edit prediction, task runners, version control). With that said, for pair-programming sessions with friends, Zed has been perfect since Linux gained screenshare support. However, there's a noticeable "pause in development" for collaboration in order to implement major features like Agentic Coding, and smaller-but-essential features like direnv integration, IME support (typing Japanese in the terminal used to be a clunky, error-prone task), dealing with the endless permutations of Python tooling so that Python files aren't a sea of red lines, etc.
no_wizard · 34m ago
Zed reminds of the days when Atom was big.
It was a good time, but it always left me wondering how long it would last as it leaned heavily on community support for nearly everything useful outside a few packages
Such a situation makes me worry about it keeping up if popularity wanes. With JetBrains for example at least I know that paying for the editor it will keep getting proper updates and support even if it isn’t the most popular (though it is quite popular currently)
drcongo · 18m ago
You can pay for Zed too. I am.
candrewlee · 5h ago
Zed is fantastic. I've been making the leap from neovim to zed lately, and it's been an great experience. Everything feels snappy, and I love how well they've integrated Vim bindings. Their agent mode is nice as well.
It's clearly an underdog to VSCode, so the extension ecosystem isn't quite there yet... but for a lot of the things I've used it for, it's sufficient. The debugger has been the big missing feature for me and I'm really glad they've built it out now - awesome work.
echelon · 5h ago
How is Zed with auto-completing Rust code?
I love how fast Windsurf and Cursor are with the "tab-tab-tab" code auto-completion, where nearly everything suggested is spot-on and the suggestions keep on rolling, almost automating the entire task of refactoring for you. This form of autocomplete works really well with TypeScript and other scripting languages.
IntelliJ / RustRover never got anywhere close to that level of behavior you can get in Cursor and Windsurf, neither in conjunction with JetBrains own models or with Co-pilot. I chalked it up as an IDE / model / language mismatch thing. That Rust just wasn't amenable to this.
A few questions:
1) Are we to that magical tab-tab-tab and everything autocompletes fluently with Rust yet? (And does this work in Zed?)
2) How does Zed compare to Cursor and Windsurf? How does it compare to RustRover, and in particular, JetBrains' command of the Rust AST?
WD-42 · 4h ago
Zed is written in Rust by a bunch of Rust lovers so it's really got first class support for it.
csomar · 1h ago
> How is Zed with auto-completing Rust code?
I think they all use LSP, so whether you use neovim or Zed there shouldn't be a difference? (not 100% sure, but that's my basic understanding of LSP).
echelon · 1h ago
The LSP support for Rust has trailed JetBrains own Rust plugin, which has long since morphed into the language-specific IDE, RustRover.
RustRover has the best AST suggestions and refactoring support out there. It works in gigantic workspaces, across build scripts, proc macros, and dynamic dispatch.
The problem with RustRover has been the lackluster AI support. I've been finding AI autocomplete generally much more useful than AST understanding, though having both would be killer.
no_wizard · 31m ago
I know they’re actively working on this, they released a few updates to the AI extension to make it modular now, so you can pick your own model for example. Soon it will let you wire up your own agents, but if I recall correctly the reason it’s a bit slower there is lack of uniform interfaces
lionkor · 5h ago
It's fantastic for Rust, it's my main IDE which I've written e.g. voltlane.net in. Fantastic software, and the LLM integration is everything you need IMO (in a good way).
mort96 · 2h ago
I was interested in Zed, but lost all interest when they started integrating "AI". I'm tired of "AI" everywhere.
I'll just stick with Neovim until something better comes around. Which probably won't happen until after the "AI" bubble bursts.
laserbeam · 2h ago
Zed was the first editor that tempted me into using AI features. It felt solid in general and AI feels mostly like autocomplete in other editors (in terms of how much it's in your face). There's definitely a place for AI models and agents in code editors, and Zed makes me feel like it's not built around them, which is great! Zed feel like "Come to us, we are making a good fast editor that also has AI." while competition feel like "Come to us, we want AI that has an editor".
mort96 · 1h ago
I'm genuinely happy it works for you. I just don't want AI in my text editor, even if you're happy with it.
oneeyedpigeon · 2h ago
I went to check out neovim and noticed it's currently sponsored by two AI products! Of course, that's one level removed from actually integrating AI in your product but, still—it's getting harder and harder to avoid altogether.
mort96 · 2h ago
Oh wow, I hadn't noticed that.
I guess it's always possible to return to Vim if Neovim starts showing signs of being steered by its sponsors.
CuriouslyC · 1h ago
At this rate you're going to be cooking over a campfire and living in a cave in a few years.
mort96 · 1h ago
Nah, the AI bubble will have popped in a few years and projects will stop sprouting AI features left and right.
CuriouslyC · 1h ago
Did the dot com crash cause software to stop integrating internet features?
mort96 · 33m ago
No, we still have software with Internet features. But Internet features went from a solution looking for a problem, to just another tool we can reach for when it's actually useful.
A whole lot of "AI" features today are in that "solution looking for a problem" category. There's a lot of "AI" in places where it really makes no sense at all. Companies and projects are afraid of missing out on what they think could be the Next Big Thing, instead of just trying to make the best software they can.
When the AI bubble bursts, it could end up like Internet features: software gets them when it genuinely makes sense, but they won't be crammed into software which has no need for it. Or it could end up like cryptocurrency: it pretty much just disappears as people realize that they don't really have any use other than to speculate on its value and to buy drugs.
Personally, my bet is that they'll end up more like cryptocurrencies. After all, "AI" doesn't just have to be a useful feature to be worth it. It has a real cost. Companies like Microsoft and Apple and Google, as well as the venture capitalists and investment funds behind the likes of Anthropic, are currently sinking VAST amounts of capital into giving "AI" away for free or heavily subsidized. At some point, it'll need to become profitable, and I don't think many people will find that the value outweighs the real, non-subsidized costs.
But we'll see.
norman784 · 1h ago
I didn't tried Zed in a while, are really intrusive the AI features? Can't it be just disabled with some configuration?
deliriumchn · 1h ago
they are not intrusive but their entire focus changed on that instead of other features. Entire Git view feels abandoned in half done state yet they spent entire month working on AI chats, AI agents, their own AI edit (that's priced 20 per month yet they boast how light and performant it is -- why isn't it free local model then and why its priced worse than copilot?)
They're moving from "making awesome code editor" into yet another "buy our ai" product
dcow · 1h ago
Wouldn’t the addition of the debugger disprove this slant? Huge feature that has nothing to do with AI.
deliriumchn · 1h ago
debugger is very far from being feature-complete, I would call it MVP at the moment; lets see if they will iterate on that or will quickly go back to new shiny thing...
Vinnl · 1h ago
AFAIK they added conflict resolution just recently, so it's not like non-AI features such as Git get no attention at all. And of course the debugger now.
nsonha · 22m ago
I'm much prefer the VS Code style when you have 2 clear sections: staged and not staged. Zed's chose the IntelliJ style which is just a bunch of checkboxes, I can see it being easier to understand for the novice, but not very intuitive from a git point of view.
mort96 · 1h ago
I don't know, I just uninstalled Zed when I read those features got added
nsonha · 27m ago
I think you're referring to autocomplete? It's much better than, say, 2 years ago when it was indeed annoying as hell. Having said I always turn it off and use agentic coding, which is not intrusive, only activate if you ask for it. This applies to all coding tools these days, autocomplete is no longer their focus.
aequitas · 2h ago
I find it very easy to avoid the AI feature in every day Zed usage. Sometimes they do come in handy though. But nog often.
mort96 · 2h ago
I don't want an editor where I have to avoid the AI features, I want an editor without AI features
Just like I want a terminal without AI features, which is why I'm no longer using iTerm2
calmoo · 1h ago
I didn't even notice iTerm has AI features? Where?
Anyway, I'm happy with Ghostty since I switched away from iTerm2 and haven't paid attention to iTerm2 development much.
reddalo · 2h ago
Me too. I don't want AI, and if it's there, I want to be able to completely remove it. Zed is forcing it, so I'm staying on VSCodium.
nurumaik · 2h ago
What's forcing AI in Zed though?
agent.enabled = false and it's gone, no?
nsonha · 31m ago
So you're interested only in tools that do nothing new and offer no added value on top of a normal code editor? Plenty of choices already, why even interested in any new thing, ever.
foldr · 1h ago
The AI features in Zed are very easy to turn off / ignore. I agree that the AI features are probably taking development time away from other features that might be more useful.
AbuAssar · 3h ago
I’m thrilled to see Zed evolve into a featured, lightweight IDE.
IMHO Debug Adapter Protocol (DAP) and Language Server Protocol (LSP) are the best things happened to programming tooling in the last decade.
(I wrote this comment in another thread about the same link but didn't hit the frontpage)
eddythompson80 · 4h ago
Ever since Linux support came out (2 years ago?), I go to check if they, finally, support “non-retina” “LoDPi” (a.k.a: a regular screen) yet, and sadly no :/
sapiogram · 2h ago
It's so incredibly frustrating. Text rendering is the primary feature of a code editor, but no one on the Zed team seems to use a non-retina screen.
It's an ugly workaround, but if you install BetterDisplay (it's a free tool) and set your LoDPI screen to HiDPI, text rendering looks good.
girvo · 4h ago
Oh I'll have to try that. Zed looks woeful on my 1440p monitor when I was trying it at work, which is a shame because I quite like it otherwise.
dkersten · 3h ago
In what way? I e been using it on my 1440p for over a year and it looks fine. Am I missing something?
GrayShade · 3h ago
On my system (Linux, 4k display without scaling) the fonts look awful, but bumping up the font weight more or less fixes it.
senko · 3h ago
Using it daily on my 1920x1200 laptop screen in Linux and works just fine.
gkbrk · 2h ago
Zed developers themselves acknowledge the blurry font issue [1], so either you just don't notice blurry fonts or 1920x1200 on a small laptop screen is HiDPI-enough to kinda hide the blurriness.
My desktop monitor is 1920x1080. On my computer and display; Vim, Emacs and VSCode are all able to render their fonts crisply while Zed is a blurry mess.
Are you using dark mode? To me, text looks absolutely awful in light mode, but okay in dark mode. Still noticeably worse than any other editors, though.
senko · 1h ago
This may be it.
I use it in dark mode and I am considerably less picky about font rendering than many people commenting on such threads.
Combined, while I can see a difference if I look closely, it doesn't bother me.
jaoane · 4h ago
They don’t support windows, they don’t support regular screens on Linux… are they a Mac shop basically?
Installing the 'stable' build with scoop works a treat.
senko · 3h ago
Using it with regular screen in Linux, works just fine.
LoganDark · 3h ago
Yes. Originally they were Mac-only, then they went open-source and the community added support for Linux and Windows, but AFAICT they've never invested in anything but Mac
avarun · 3h ago
Most startups are
writebetterc · 2h ago
It's surprisingly slow. Switching files in the tab list has a noticeable delay. Typing is higher latency than both Emacs (lsp-mode activated) and my web browser. Also uses approximately 60MiB more than my Emacs. It starts fast though!
I wouldn't complain about this stuff if it wasn't for their tagline being 'it's fast' and they're losing to Emacs Lisp (not a language amenable to being very fast) with a highly optimized C core.
I looked at their plugins, they're compiled into WASM and run in some VM. Maybe that's part of it?
frou_dh · 1h ago
Talking of Emacs, there is a very well designed DAP-based debugger available as the 'dape' package.
The way it's designed (incl. having no dependencies) suggests that they will be angling for it to be included with stock Emacs at some point.
GrayShade · 1h ago
> I looked at their plugins, they're compiled into WASM and run in some VM. Maybe that's part of it?
No. The ones I've looked just set up stuff, like launching a language server. They shouldn't be involved in typing.
I think it's related to the GPU usage. It's easy to introduce delays when you do GPU compositing, and the OS will already be doing its own.
As for emacs, IIRC they did some ugly things to update the UI directly instead of going through the normal event loop, which was causing compatibility issues later on.
lordofgibbons · 5h ago
I've gone full-time with Zed for the past month or so and really like it. Love the fast start times. There was a blurry font issue on linux, but that seems to have been fixed for me. Not sure what caused it.
Rucadi · 2h ago
Until zed doesn't work on windows (publicly) unfortunately can't use it in my working computer
The opengl one fails on my PC but the "regular one" (?) zed.exe seems to work. Didn't test much as I have discovered that today :-)
tomjuggler · 5h ago
Not Zed's fault but I'm still stuck with VSCode because Zed doesn't support PLatformIO (or rather PlatformIO doesn't support Zed).
I'm guessing that this extension support problem will continue to be a barrier to uptake for a while.
Cthulhu_ · 2h ago
This is becoming a recurring issue; plenty of innovation being put in new and faster tooling to replace the JS-based daily drivers we've had for the past decade+, but there's a huge ecosystem of 3rd party addons to those now which is slowing adoption down; I'm also thinking of Prettier/ESLint vs Biome, the only thing stopping us from going full Biome is that we need some ESLint plugins.
That said, it's getting better; as another commenter pointed out, LSP is one of the best things to happen to this space. There should be a standard for editor plugins, too.
zamalek · 5h ago
> Not Zed's fault
Zed only supports language extensions, so it is in part responsible. If you're using embedded rust then PlatformIO isn't really needed; probe-rs is extremely capable and straightforward.
taminka · 1h ago
dear zed ppl, PLEASE PLEASE PLEASE configure your language detection properly wrt C and C++! every single editor on earth makes this exact same mistake where they think all C is valid C++ (it's not, at all), and mistakenly recognises C files as C++, even when there's an accompanying compile_commands.json file that specifies a C standard and even when files contain invalid C++ (but valid C)
it's a delightful little editor if it weren't for this thing...
rvz · 5h ago
I think competent software engineers should actually read the "Under the hood" section, before they lose the core understanding on how debuggers work and are integrated into editors.
Upon reading the Rust code implementing the Debug Adapter Protocol (DAP) in Zed, some very junior SWEs will quickly point out that they would prefer only "self-documenting code" and would go as far as to removing all comments or even believe that "If it has comments, its probably bad code".
For sophisticated software that implements a defined protocol that is architected to be scalable in any piece of complex software, I prefer these comments that explains why a particular interface is designed the way it is and how it fits into the software (Zed) in this case if it were to be widely re-used like a plugin system.
This blog post is excellent in explaining this debugger integration in the editor and it makes me want to consider using Zed; it just needs an improved extension ecosystem.
It's a niche feature, but what's keeping me from switching yet is that they zed doesn't support ctrl+scroll to zoom/change font size yet.
Because I am accustomed to a non-US keyboard layout that doesn't make the regular key bindings for changing zoom easy, I got too used to doing it this way.
It's honestly looking to be a great modern IDE with almost everything I'm wishing for.
nlitened · 3h ago
It is funny that accidental scroll while holding Ctrl changing font size is one of my most hated features in IDEs, like who the hell ever needs to change their optimal font size to any other value. It's fascinating to me that this is a dealbreakingly important feature for someone else.
j16sdiz · 2h ago
You use them in pair programming, when you peer sit a little bit further
dmit · 2h ago
Live coding during a presentation or on stream is another use case in addition to the sibling comments.
7bit · 3h ago
I often use it when sharing my screen. I like the feature quite a lot.
senko · 3h ago
May I ask which layout is that? On most that I have encountered (using hr daily), + and - don't require modifiers.
yangcheng · 2h ago
I wish Zed can better support claude code, like offering native IDE integration. with Claude code SDK this seems doable?
> To simplify the setup process, we've introduced locators, a system that translates build configurations into debug configurations. Meaning that you can write a build task once in tasks.json and reference it from debug.json — or, even better, rely on Zed's automatic configuration.
Does that work if my build is Docker based?
rs_rs_rs_rs_rs · 5h ago
I havent's keep up with Zed, how's the Windows version coming along? Is anyone here using it?
fancy_pantser · 5h ago
I've been using the unofficial builds via scoop for the last two months. It's working great so far. I use it on a Macbook as well and I haven't found any features that are missing or buggier on Win11. Really enjoying the new agent version of the AI assistant, which I use with both Claude API and devstral locally via Ollama.
Unfortunately, "here" is not accurate. Not having a watch window, a stack trace view, and no mention of data breakpoints in the announcement still keeps the "beta" tag. I know those features will arrive eventually, but what is described is definitely not sufficient for 97% of my debugging sessions.
I would also have liked to see more in the announcement of multiple simultaneous debug sessions, and on how multithreaded debugging is planned. There are really cool things that can be done with multithreaded debugging further down the line that I'd be interesting in hearing about (like how RemedyBG has a DAW-like UI for freezing certain threads, or hitting one button to "solo" a thread and freeze all others).
> New views: While we support all the fundamental views, we're planning on adding more advanced views such as a watch list, memory view, disassembly view, and a stack trace view
[1] https://zed.dev/blog/debugger#whats-next
With that said, Zed has effectively replaced all of Emacs for me, besides Magit. Additionally, typing in other editors feels noticeably higher latency than Zed :)
I've been daily driving Zed for almost a year now -- works best on TypeScript, Rust, and Go projects, in my opinion.
There's just so much functionality Zed has to build out to compete with modern editors (agentic coding, collaboration, debugging, edit prediction, task runners, version control). With that said, for pair-programming sessions with friends, Zed has been perfect since Linux gained screenshare support. However, there's a noticeable "pause in development" for collaboration in order to implement major features like Agentic Coding, and smaller-but-essential features like direnv integration, IME support (typing Japanese in the terminal used to be a clunky, error-prone task), dealing with the endless permutations of Python tooling so that Python files aren't a sea of red lines, etc.
It was a good time, but it always left me wondering how long it would last as it leaned heavily on community support for nearly everything useful outside a few packages
Such a situation makes me worry about it keeping up if popularity wanes. With JetBrains for example at least I know that paying for the editor it will keep getting proper updates and support even if it isn’t the most popular (though it is quite popular currently)
I love how fast Windsurf and Cursor are with the "tab-tab-tab" code auto-completion, where nearly everything suggested is spot-on and the suggestions keep on rolling, almost automating the entire task of refactoring for you. This form of autocomplete works really well with TypeScript and other scripting languages.
IntelliJ / RustRover never got anywhere close to that level of behavior you can get in Cursor and Windsurf, neither in conjunction with JetBrains own models or with Co-pilot. I chalked it up as an IDE / model / language mismatch thing. That Rust just wasn't amenable to this.
A few questions:
1) Are we to that magical tab-tab-tab and everything autocompletes fluently with Rust yet? (And does this work in Zed?)
2) How does Zed compare to Cursor and Windsurf? How does it compare to RustRover, and in particular, JetBrains' command of the Rust AST?
I think they all use LSP, so whether you use neovim or Zed there shouldn't be a difference? (not 100% sure, but that's my basic understanding of LSP).
RustRover has the best AST suggestions and refactoring support out there. It works in gigantic workspaces, across build scripts, proc macros, and dynamic dispatch.
The problem with RustRover has been the lackluster AI support. I've been finding AI autocomplete generally much more useful than AST understanding, though having both would be killer.
I'll just stick with Neovim until something better comes around. Which probably won't happen until after the "AI" bubble bursts.
I guess it's always possible to return to Vim if Neovim starts showing signs of being steered by its sponsors.
A whole lot of "AI" features today are in that "solution looking for a problem" category. There's a lot of "AI" in places where it really makes no sense at all. Companies and projects are afraid of missing out on what they think could be the Next Big Thing, instead of just trying to make the best software they can.
When the AI bubble bursts, it could end up like Internet features: software gets them when it genuinely makes sense, but they won't be crammed into software which has no need for it. Or it could end up like cryptocurrency: it pretty much just disappears as people realize that they don't really have any use other than to speculate on its value and to buy drugs.
Personally, my bet is that they'll end up more like cryptocurrencies. After all, "AI" doesn't just have to be a useful feature to be worth it. It has a real cost. Companies like Microsoft and Apple and Google, as well as the venture capitalists and investment funds behind the likes of Anthropic, are currently sinking VAST amounts of capital into giving "AI" away for free or heavily subsidized. At some point, it'll need to become profitable, and I don't think many people will find that the value outweighs the real, non-subsidized costs.
But we'll see.
They're moving from "making awesome code editor" into yet another "buy our ai" product
Just like I want a terminal without AI features, which is why I'm no longer using iTerm2
Anyway, I'm happy with Ghostty since I switched away from iTerm2 and haven't paid attention to iTerm2 development much.
agent.enabled = false and it's gone, no?
IMHO Debug Adapter Protocol (DAP) and Language Server Protocol (LSP) are the best things happened to programming tooling in the last decade.
(I wrote this comment in another thread about the same link but didn't hit the frontpage)
Github issue for context: https://github.com/zed-industries/zed/issues/7992
My desktop monitor is 1920x1080. On my computer and display; Vim, Emacs and VSCode are all able to render their fonts crisply while Zed is a blurry mess.
[1]: https://github.com/zed-industries/zed/issues/7992
I use it in dark mode and I am considerably less picky about font rendering than many people commenting on such threads.
Combined, while I can see a difference if I look closely, it doesn't bother me.
https://github.com/deevus/zed-windows-builds
Installing the 'stable' build with scoop works a treat.
I wouldn't complain about this stuff if it wasn't for their tagline being 'it's fast' and they're losing to Emacs Lisp (not a language amenable to being very fast) with a highly optimized C core.
I looked at their plugins, they're compiled into WASM and run in some VM. Maybe that's part of it?
https://elpa.gnu.org/packages/dape.html
The way it's designed (incl. having no dependencies) suggests that they will be angling for it to be included with stock Emacs at some point.
No. The ones I've looked just set up stuff, like launching a language server. They shouldn't be involved in typing.
I think it's related to the GPU usage. It's easy to introduce delays when you do GPU compositing, and the OS will already be doing its own.
As for emacs, IIRC they did some ugly things to update the UI directly instead of going through the normal event loop, which was causing compatibility issues later on.
https://github.com/deevus/zed-windows-builds/releases
The opengl one fails on my PC but the "regular one" (?) zed.exe seems to work. Didn't test much as I have discovered that today :-)
I'm guessing that this extension support problem will continue to be a barrier to uptake for a while.
That said, it's getting better; as another commenter pointed out, LSP is one of the best things to happen to this space. There should be a standard for editor plugins, too.
Zed only supports language extensions, so it is in part responsible. If you're using embedded rust then PlatformIO isn't really needed; probe-rs is extremely capable and straightforward.
it's a delightful little editor if it weren't for this thing...
Upon reading the Rust code implementing the Debug Adapter Protocol (DAP) in Zed, some very junior SWEs will quickly point out that they would prefer only "self-documenting code" and would go as far as to removing all comments or even believe that "If it has comments, its probably bad code".
For sophisticated software that implements a defined protocol that is architected to be scalable in any piece of complex software, I prefer these comments that explains why a particular interface is designed the way it is and how it fits into the software (Zed) in this case if it were to be widely re-used like a plugin system.
This blog post is excellent in explaining this debugger integration in the editor and it makes me want to consider using Zed; it just needs an improved extension ecosystem.
[0] https://zed.dev/blog/debugger#under-the-hood
Because I am accustomed to a non-US keyboard layout that doesn't make the regular key bindings for changing zoom easy, I got too used to doing it this way.
It's honestly looking to be a great modern IDE with almost everything I'm wishing for.
Does that work if my build is Docker based?
https://github.com/deevus/zed-windows-builds
It is finally at the review stage, I really hope it can get merged soon!