Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Zed on Linux Is Here

zed.dev

Post reply on HN
Print view View original

431–440 of 703 posts

Re: Zed on Linux Is Here

#431

Post by worthless-trash »

jhoechtl wrote: post #254
zelphirkalt wrote: post #235

Earlier quoted context omitted.

I think Emacs does this too, if you configure it, or even by default, using its backup files, that go by #some_name# or similar.

While I love Emacs it's not like this. Scratch buffer? C-c C-x and all is gone without any warning.

Scratch is (I think) intended for use for executing 'this session' elisp code as the buffer is set to lisp interfactive mode, not intended for where you store your scratch text.

Other buffers behave differently, maybe scratch isn't useful for a large number of emacs users, however scratch is working as designed.

Re: Zed on Linux Is Here

#432

Post by microflash »

handsaway wrote: post #26

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…

> 2. Integration with the Typescript language server was just not as good as VSCode. I can't pin down exactly what was wrong but the autocompletions in particular felt much worse. I've never worked on a language server or editor so I don't know what's on zed/VSCode and what's on the TS language server.

I had similar experience with JavaScript where it kept showing me errors (usually for ESM imports) even though things were fine. In VSCode, things worked without fuss. I've been testing out JetBrains Fleet [1] as well and its language support is far superior compared to Zed.

[1]: https://www.jetbrains.com/fleet/

Re: Zed on Linux Is Here

#433

Post by apatheticonion »

iamnbutler wrote: post #400
apatheticonion wrote: post #367

What does Zed use as the UI toolkit? Looking at the code they have a handmade UI toolkit called gpui. Does that map directly to OS/DE specific GUI bindings? I can't find where that's happening EDIT: Holy sh*t, they actually have bindings for each OS and built a Rust abstraction on top of that. That's pretty wild https://github.com/zed-industries/zed/blob/main/crates/gpui/...

We have a couple of blog posts digging into gpui, but here is one from just after rewriting and shipping gpui2: https://zed.dev/blog/gpui-ownership We’ve slowly been building out gpui to be super ergonomic and fluid for us to build the kind of UI we need to. As a designer that just picked up Rust last February it’s been really nice to have something that is so comfortable to work with without compromising our perform…

That's amazing, thanks for sharing this. Native desktop UIs are an area of interest for me so this will be an exciting read for me

Re: Zed on Linux Is Here

#435

Post by lsllc »

iamnbutler wrote: post #414
lexoj wrote: post #352

The only reason why I dropped (and Im not alone) using Zed is the arcaic UI sublime-like search functionality. Please revisit that part because I really want to use ZED.

This is actually the first time I’ve seen someone unhappy with search - can you tell me a bit more what you are looking for? There is lots of room for improvement of course, but I’d love to hear what your desired search experience is.

nvim+lazyvim+telescope (which uses ripgrep and/or fzf). Fantastic, that's the gold standard for finding files, grepping, looking for references to variables etc. Love it.

Re: Zed on Linux Is Here

#436

Post by silisili »

varispeed wrote: post #302
handsaway wrote: post #26

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.

I grew up a damn good HPB Q1 player at 250ish ms.

If you type and wait for the letter, I could see that being annoying. My brain works more in waves, my hands type a block and it's there on the screen. I've never once thought of character latency, but maybe that's my HPB roots.

Re: Zed on Linux Is Here

#439

Post by 29athrowaway »

It worked well out of the box, but the font rendering is a bit off. Using x11, not wayland.

The default font was a bit small on a 4K resolution by default, but it was easy discover how to enlarge it.

Opening a Rust project worked flawlessly without any configuration at all.

Re: Zed on Linux Is Here

#440

Post by FireBeyond »

mirpa wrote: post #387
jay_kyburz wrote: post #332

Earlier quoted context omitted.

If you haven't tried a 144hz or even a 240hz gaming PC, you should. You can really feel the difference dragging things around the screen. (I'm not sure I would notice typing, but for dragging windows around I could never go back to 60fps.)

I can certainly tell difference between 60 and 120 Hz in fast paced games, but I would not notice it in UI.

I thought so too, but for a while I had 2 144Hz monitors on my Mac Pro[1] and very much noticed it in the UI, window dragging was smoother, browser scrolling too, absolutely noticeable.

[1] Then Apple released the Pro Display and Big Sur and people wondered "how does the math work for a 6K display and bandwidth?" The answer, they completely fucking broke DP 1.4. Hundreds of complaints, different monitors, different GPUs, all broke by Big Sur to this day just so Apple could make their 6K display work.

My screens could do 4K HDR10 @ 144 Hz. After Big Sur? SDR @ 95 Hz, HDR @ 60Hz. Ironically I got better results telling my monitors to only advertise DP 1.2 support, then it was SDR@120, HDR@95Hz.

Studiously ignored by Apple because they broke the standard to eke out more bandwidth.

Post reply on HN