Live data from Hacker News

Linux When?

zed.dev

61–70 of 169 posts

Re: Linux When?

#61

I really appreciate how Zed tries to tailor make and ensure their app looks and feels native on Linux. One thing that scares me with it though is the lock in of the multiplayer features. I can see it forcing me to use it and not my preferred editor, because other people use Zed. Would love it if we were not only platform independent but also editor independent regardless of social pressure.

I am generally wary of anything that proposes to monetize the process of doing my core work.

I recognize that that attitude makes marketing and selling a product to developers difficult, though. If they changed from a CLA to a DCO I'd feel less uneasy about it, but but is that something their investors and business can permit?

Re: Linux When?

#62

> On macOS, for example, Zed makes direct use of Metal. We have our own shaders, our own renderer, and we put a lot of effort into understanding macOS APIs to get to 120FPS. So they are taking the exact opposite approach of Electron (VS Code). In my mind, if you're someone who types in HN comments in a rage because your text editor (VS Code) eats up 200+ MB ram, you don't get to cry about Zed not being supported on L…

> In my mind, if you're someone who types in HN comments in a rage because your text editor (VS Code) eats up 200+ MB ram, you don't get to cry about Zed not being supported on Linux from day one, because you can't have your cake and eat it too - if you want it on your platform, you gotta wait for the shaders to be written.

This is certainly one takeaway. On the other hand, this very blog post points out that a community member, Dzmitry Malyshau, did the work to get the program working on the OS he uses. Malyshau does not work for Zed, which is a for-profit company; as far as I can see, he gets nothing out of working on Zed, except that he and other Linux users get to use it. Perhaps, rather than characterizing Linux users as whiny, we could take away the idea that many Linux users are willing to put in quite a lot of work to make things better for each other.

Re: Linux When?

#63

> On macOS, for example, Zed makes direct use of Metal. We have our own shaders, our own renderer, and we put a lot of effort into understanding macOS APIs to get to 120FPS. So they are taking the exact opposite approach of Electron (VS Code). In my mind, if you're someone who types in HN comments in a rage because your text editor (VS Code) eats up 200+ MB ram, you don't get to cry about Zed not being supported on L…

Or… use one of the existing cross platform toolkits that have existed for decades. Text Editors, traditionally, did not require shaders to run or be performant, and not require entire systems worth of RAM.

If you want a shaderless text editor, just use NotePad. But the world has moved on and people like their text to look nice.

Re: Linux When?

#64

What is the accessibility story with Zed? I have a vague memory that atom had none of it.

Right now: mixed. We provide both user defined themes and theme overrides that let people color-correct things as they need, we have a strong cultural focus on keyboard accessibility for all UI elements, you can increase or decrease the font size in the editor and the UI, and we have strong support for IME on macOS and will be extending that to Windows and Linux.

However, our accessibility to screen readers is non-existent. I have ambitions to incorporate AccessKit but it's a bit of a project due to the lack of a clear guide on how to implement it. That said, I already made some progress based on the old egui PR and we should have all the pieces we need once I have time to actually do it.

We also lack any way to tab through our UI elements to select each piece in turn. This one I have yet to do any thinking on, particularly as the tab key already does a lot of work in a code editor. I'm sure there's prior art here, I just haven't looked at it yet.

So, piecemeal and insufficient for many cases, usable for some others. I'm very interested in improving this but we still have a lot to do.

Re: Linux When?

#66
post #45

Earlier quoted context omitted.

Out of curiosity, how many of them run at 120 FPS? (honest question - I've never looked into it myself)

This is the first time I see FPS mentioned for a text editor. Is this something that matters or just an pointless metric utilized as selling point?

Fps in itself is not important, but it is a substitute for input latency, and if your keystrokes start lagging it feels sluggish. At least historically electron based editors (like atom) has been feeling significantly more sluggish than sublime text or vim with a decent terminal emulator.

Re: Linux When?

#67
post #12

Earlier quoted context omitted.

Some troubleshooting tips: - Move your mouse cursor to the "Zed Industries" icon in the upper-left-hand-corner, then click. - This "hypertext link" will instruct your browser to load the site's root "index.html", sometimes known as a "landing page". - The "landing page" is a great place to start if you're unfamiliar with a site or product! Here, you'll find the following text prominently displayed: "Zed is a high-per…

To be fair, the logo is like 2px tall on Firefox Android...

that is my bad – someone flagged this before and I forgot to fix it. A quick fix is deploying now!

Re: Linux When?

#68

> On macOS, for example, Zed makes direct use of Metal. We have our own shaders, our own renderer, and we put a lot of effort into understanding macOS APIs to get to 120FPS. So they are taking the exact opposite approach of Electron (VS Code). In my mind, if you're someone who types in HN comments in a rage because your text editor (VS Code) eats up 200+ MB ram, you don't get to cry about Zed not being supported on L…

MoltenVK is also a thing. Whatever small translation overhead it incurs is probably not that important for a text editor. And then you get a cross-platform API: not just Linux, but Windows as well. Maybe also other more niche OSes as well.

Re: Linux When?

#69

I'm curious why Zed chose Blade over wgpu/wgpu-hal. There's a bit of detail here: https://github.com/zed-industries/zed/issues/7015 But I'd be curious to read a longer writeup on the tradeoffs and how they came to their decision.

This is a pretty good answer: https://github.com/gfx-rs/wgpu/tree/trunk/wgpu-hal

The "design of WebGPU" is a problem. It's designed for the web to be secure and sandboxed so the API design reflects that. This is not a good thing on desktop.

Re: Linux When?

#70

If you care a lot about Linux support, Lapce is a very promising alternative. Much like Zed, it also is written in Rust with native GPU-based rendering and a shared focus on enabling integration with modern IDE technologies such as LSP servers, tree-sitter parsers and DAP for debugging.

you can build zed for linux, today :) https://github.com/zed-industries/zed/blob/main/docs/src/dev...
Post reply on HN