4 ms·

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

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).

aequitas 1y 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 1y 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 1y 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 1y ago
      You can pay for Zed too. I am.
      - no_wizard 1y ago
        Paying for zed isn’t the same as paying for extensions to be well maintained. They’re not all in house
        drcongo 1y ago
        Ahh, I see what you mean now and yeah, I agree.
    - hombre_fatal 1y ago
      Leaning on community support seems ideal because it means you've built a powerful plugin API and people can implement features. As opposed to having a weak plugin API where all progress depends on the tiny internal team. The latter suffers more than the first if popularity wanes. In Atom's case, its lunch was eaten by VSCode which was similar but just better. Based on web tech but with better performance and just as powerful of a plugin API. It wasn't the fact that they let people implement plugins that killed Atom, and they would have been in an even worse situation had they not had a good plugin API.
    - pjmlp 1y ago
      And Sublime, BBEdit, TextMate, Notepad++, Ultraedit, Slick, vi, vim, XEmacs, Emacs, nano, joe, jEdit,....
keyle 1y ago
I agree but at the rate the Zed team is working at, we're not far off!
- laserbeam 1y ago
  Oh yeah, of course :). My argument is they're just premature in declaring readiness.
odie5533 1y ago
100% of my debug sessions are with plain breakpoints and stepping. So it's here for me!
happy-dude 1y 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 [1] https://zed.dev/blog/debugger#whats-next https://zed.dev/blog/debugger#whats-next
deleted 1y ago
[deleted]
nixpulvis 1y ago
Is there a tracking issue for watching variables and data breakpoints? I'd like to see that as well.
- anthony-eid 1y ago
  Here's the PR for variable/expression watching: https://github.com/zed-industries/zed/pull/32743 https://github.com/zed-industries/zed/pull/32743 I don't think there's an issue for data breakpoints, but you can make one for us
anthony-eid 1y ago
Hey Laserbeam, I'm one of the devs that made the debugger and the one that wrote the article. We do have a basic stack trace view that basically all debuggers support. What's coming out in the near future is a stack trace view in our multi buffer system. In fact, you can use the "show stack trace" action while in an active debug session to expand the call stack in a multi buffer, where each excerpt is a frame. It's just not up to the quality that I and several others expect from Zed, so I didn't advertise it. There's also a PR for a watching variables/expression that is going to be merged in a couple of days. The functionality is done, but we didn't want to add a feature so close to launch that wasn't fully tested. Support for data breakpoints will come in the near future. I can't say when because we're planning on focusing on automatic configuration for a while, but it is a priority. We do support simultaneously debugging multiple sessions at the same time and multithreaded debugging too. There's still more to do with it, but the support is definitely there!
- laserbeam 1y ago
  I am VERY confident you guys have everything I mentioned either half working or coming shortly, so I'm not worried. I just saw a "the debugger is here!" announcement, then read the announcement, and saw what's still under todo... My reaction is "well, it's not here, it'll be here in a few weeks". And that's ok ^.^ Am impressed by the under-the-hood discussion though. Keep up the great work!
  - anthony-eid 1y ago
    Thank you for the positive energy and I'm glad you liked the under the hood section!

aequitas 1y 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 1y 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 1y 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 1y ago
    You can pay for Zed too. I am.
    - no_wizard 1y ago
      Paying for zed isn’t the same as paying for extensions to be well maintained. They’re not all in house
      - drcongo 1y ago
        Ahh, I see what you mean now and yeah, I agree.
  - hombre_fatal 1y ago
    Leaning on community support seems ideal because it means you've built a powerful plugin API and people can implement features. As opposed to having a weak plugin API where all progress depends on the tiny internal team. The latter suffers more than the first if popularity wanes. In Atom's case, its lunch was eaten by VSCode which was similar but just better. Based on web tech but with better performance and just as powerful of a plugin API. It wasn't the fact that they let people implement plugins that killed Atom, and they would have been in an even worse situation had they not had a good plugin API.
  - pjmlp 1y ago
    And Sublime, BBEdit, TextMate, Notepad++, Ultraedit, Slick, vi, vim, XEmacs, Emacs, nano, joe, jEdit,....

keyle 1y ago

I agree but at the rate the Zed team is working at, we're not far off!

laserbeam 1y ago
Oh yeah, of course :). My argument is they're just premature in declaring readiness.

odie5533 1y ago

100% of my debug sessions are with plain breakpoints and stepping. So it's here for me!

happy-dude 1y 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 [1] https://zed.dev/blog/debugger#whats-next https://zed.dev/blog/debugger#whats-next

deleted 1y ago

[deleted]

nixpulvis 1y ago

Is there a tracking issue for watching variables and data breakpoints? I'd like to see that as well.

anthony-eid 1y ago
Here's the PR for variable/expression watching: https://github.com/zed-industries/zed/pull/32743 https://github.com/zed-industries/zed/pull/32743 I don't think there's an issue for data breakpoints, but you can make one for us

anthony-eid 1y ago

Hey Laserbeam, I'm one of the devs that made the debugger and the one that wrote the article. We do have a basic stack trace view that basically all debuggers support. What's coming out in the near future is a stack trace view in our multi buffer system. In fact, you can use the "show stack trace" action while in an active debug session to expand the call stack in a multi buffer, where each excerpt is a frame. It's just not up to the quality that I and several others expect from Zed, so I didn't advertise it. There's also a PR for a watching variables/expression that is going to be merged in a couple of days. The functionality is done, but we didn't want to add a feature so close to launch that wasn't fully tested. Support for data breakpoints will come in the near future. I can't say when because we're planning on focusing on automatic configuration for a while, but it is a priority. We do support simultaneously debugging multiple sessions at the same time and multithreaded debugging too. There's still more to do with it, but the support is definitely there!

laserbeam 1y ago
I am VERY confident you guys have everything I mentioned either half working or coming shortly, so I'm not worried. I just saw a "the debugger is here!" announcement, then read the announcement, and saw what's still under todo... My reaction is "well, it's not here, it'll be here in a few weeks". And that's ok ^.^ Am impressed by the under-the-hood discussion though. Keep up the great work!
- anthony-eid 1y ago
  Thank you for the positive energy and I'm glad you liked the under the hood section!