Live data from Hacker News

Zed on Linux Is Here

zed.dev

401–410 of 703 posts

Re: Zed on Linux Is Here

#401
I like using zed when I'm on the MacBook. It's quite fast, looks good and has some neat features like multi file editing.

But I don't get the utility of all the collaboration features. It's noise to me, and feels like they could have invested that energy in other areas.

I work in a small fully remote team, and our tool of choice for collaboration is git. Why would I want to edit the same file while someone else is editing it too? Who will commit it? If I want to discuss a part of the code with someone screen sharing works perfectly. There's no need to bring in simultaneous editing.

It's such a technically hard feature to develop but just doesn't seem to have any utility for me.

Re: Zed on Linux Is Here

#403
post #364

I have fallen in love with Zed on Mac, so glad to see it will still be an option when I switch back to Linux. My main concern is the collaboration features; just seems like a nonsensical addition. I have zero influence over what editors my teams use, and I work with dozens of different people on collaborative development every year - I'm not going to be persuading anyone to switch, and so that feature is just dead co…

I have felt similarly about collab tools. Even if the tools in an editor look cool, someone on the team is gonna get left out because they use a different tools. It feels a bit like the wrong layer for the collab tools to live.

Indeed, Tuple is a better solution. That said, I think Zed is a great text editor.

Re: Zed on Linux Is Here

#404

Earlier quoted context omitted.

Not to my knowledge, outside of whatever Debian comes with. Keep in mind this was on a Chromebook - so it would have been running in a VM on a rather memory restricted system. That said, VSCode would have been running in the same parameters. Just found the file. 42MB on a single line. Takes 5 seconds to open in vim, and about 3 seconds for the right arrow to move the cursor one char over. Nothing like gedit, but slow…

I'm pretty sure this is syntax highlighting. It's a known issue to be slow for large files in Vim because it is synchronous. Try starting Vim with syntax highlighting off: vim -c 'syn off'

[dead]

Re: Zed on Linux Is Here

#405

I tried zed for a few weeks because I'm generally sympathetic to the "use a native app" idea vs Electron. I generally liked it and its UX but: 1. VSCode is pretty damn fast to be honest. Very rarely is my slowdown in my work VSCode loading. Maybe I don't open very large files? Probably 5k lines of typescript at most. 2. Integration with the Typescript language server was just not as good as VSCode. I can't pin down e…

Okay, call me weird, but why our standards have fallen so low? VSCode may appear fast, but still has massive latency. The Zed website claims 97ms. I can feel it is laggy. Why can't we have response time under 1ms? Even 5ms would be a massive improvement. For me latency is a massive productivity killer as it feels like walking in a swamp and it always puts me off.

[dead]

Re: Zed on Linux Is Here

#406
I tried on Intel GPU ( dell xps 9305 ) with Ubuntu 20.04 and it does not open a window, with --foreground that's what I got:

zed --foreground

MESA-INTEL: warning: Performance support disabled, consider sysctl dev.i915.perf_stream_paranoid=0

Is there even more debug available?

Re: Zed on Linux Is Here

#407
post #107
post #91

Looks like they're developing their own Apache-licensed GUI framework for this, called GPUI. I think of text handling as one of the trickier parts of building such a framework, so one specifically made to support a text editor would seem to be a pretty good foundation for a general purpose GUI toolkit. I wonder if they (or someone else) will pursue it as an alternative to Qt.

GPUI is very cool, they have blogged about it before. https://zed.dev/blog/videogame Many UI libraries being built today want to be very forward-focused, so they focus on being as general as possible. This does make some sense, especially considering that, for better or worse, using a web browser engine as a UI has become increasingly popular of a decision. However, in the end this leads to almost all new "greenfield…

Thanks for the links. The approach described in that blog post seems like it could actually achieve crisp, native-looking text. What a welcome improvement that would be compared to the blurry, misshapen, overlapping, or poorly laid out results I've seen from other new GUI frameworks.

Re: Zed on Linux Is Here

#409

I tried zed for a few weeks because I'm generally sympathetic to the "use a native app" idea vs Electron. I generally liked it and its UX but: 1. VSCode is pretty damn fast to be honest. Very rarely is my slowdown in my work VSCode loading. Maybe I don't open very large files? Probably 5k lines of typescript at most. 2. Integration with the Typescript language server was just not as good as VSCode. I can't pin down e…

I think people just have very different tolerances for latency and slowness. I keep trying different editors (including VS Code), and I always end up going back to Neovim because everything else just feels sluggish, to the point where it annoys me so much I'm willing to put up with all the configuration burden of Neovim because of it. I tried out Zed and it actually feels fast enough for me to consider switching.

> people just have very different tolerances for latency and slowness

I've honestly never considered this and it's genius. I have always been surprised when people recommend kitty as a "fast" terminal when it takes 200ms (python interpreter) to start up, which is unbearable to me.

But yeah, people sometimes just open a couple and see speed in other areas that I don't care about.

Re: Zed on Linux Is Here

#410
post #107
post #91

Looks like they're developing their own Apache-licensed GUI framework for this, called GPUI. I think of text handling as one of the trickier parts of building such a framework, so one specifically made to support a text editor would seem to be a pretty good foundation for a general purpose GUI toolkit. I wonder if they (or someone else) will pursue it as an alternative to Qt.

GPUI is very cool, they have blogged about it before. https://zed.dev/blog/videogame Many UI libraries being built today want to be very forward-focused, so they focus on being as general as possible. This does make some sense, especially considering that, for better or worse, using a web browser engine as a UI has become increasingly popular of a decision. However, in the end this leads to almost all new "greenfield…

Lots of the app’s UI right now is a layer of components on top of gpui (check out the ui crate!) that are pretty Zed-specific at the moment.

Some of these things will likely be made more general and have dedicated gpui elements built for them (button, input…)

I think not rushing to cover everything right out the gates is giving us the time to feel out apis that feel good to write and work well for us. Hopefully in the near future that translates to a UI library that is awesome for the whole rust community to use.

Post reply on HN