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

551–560 of 703 posts

Re: Zed on Linux Is Here

#551

Post by andrepd »

jchw wrote: post #88

Man, I'm conflicted. I mean, Zed works pretty damn well. So far my biggest annoyance with Zed though is that it's constantly trying to download language servers and other tools and run them. And sure, that's handy, but 1. I don't really want it, I'd much rather only use distribution-provided tools. 2. It doesn't work at all on NixOS, so it's just wasting its time and our bandwidth constantly downloading and trying to…

If any zed devs are in this thread: I highly highly suggest that any auto-download or upload (be it telemetry, plugins being downloaded, and worse: plugins uploading god knows what) is opt-in or at the very least easy to opt-out.

The eagerness to download stuff without my consent at the moment precludes me from using this e.g. in a job that touches a sensitive proprietary codebase.

Re: Zed on Linux Is Here

#552

Post by andrepd »

llagerlof wrote: post #72

Just a suggestion. One of the best features of pure text editors (and incredible, not all of them implement it) is autosave keeping the "unsaved" state of the file. For example, if you make some changes in a file (new or not), don't save the changes, close and open the editor, the state of the opened files are kept like I never had closed the editor. The unsaved files are still unsaved. New edited files are still the…

So does sublime. Indeed I rely on this behaviour almost unconsciously.

Re: Zed on Linux Is Here

#553

Post by barnabee »

spiderice wrote: post #430
zamalek wrote: post #312

Earlier quoted context omitted.

Helix has been stalled for a few months, and there are issues that make it frustrating to use at times. For example, :Ex and friends have been relegated to the plugin system (the root cause of the stall, it hasn't been merged). I still prefer it to the config overhead of nvim (as well as the kakoune-style movements!), but the paper cuts have hit a threshold and I've started writing my own text editor (I'd probably us…

The Helix community is the worst part about Helix. Especially the not so benevolent dictator of the project. Way too many comments like “if you don’t like how it’s done go use a different editor” instead of listening to feedback. That’s fine if they don’t care about adoption (they publicly say they don’t), but an actively hostile community doesn’t give me confidence in the editor, despite it being quite nice.

My experience is rather different.

The community is welcoming, and will help solve issues. However, it’s true (and good IMHO) that the project seems to have a strong idea of what is and is not a core feature. They prioritise building what you might call the Helix editing model and the Helix vision for what an editor should be.

Importantly, Helix isn’t (or doesn’t appear to be) trying to become something approaching an OS, or to be a faster, easier to configure way to get an editor that works like [your preferred configuration of] vim or emacs with lower input latency.

I applaud these things! I like the Helix model more than the vim or emacs models, and the project’s priorities for what should and shouldn’t be in an editor core are pretty well aligned with my own. I do not find I’m desperate for plugins to fix some major deficiency, though I’m sure I’ll use a few once they become available.

This is all what I want to see and fits my definition of a good “benevolent dictator”, maintaining focus and taking tough decisions.

I do maintain a reasonable set of extra keybindings and small configuration changes, as well as a very slightly modified theme [0], but I don’t think many of them are essential and I try pretty hard not to conflict with Helix defaults or radically diverge from the Helix editing model.

It works for me right now, and keeps getting better (rather quickly if you install from git as I do). I’m excited for the future, especially seeing some of the features and improvements moving through PRs.

YMMV.

[0] https://gist.github.com/barnabee/82f39d02a85291b0045f53f2473...

Re: Zed on Linux Is Here

#554

Post by pmontra »

jojobas wrote: post #516
weinzierl wrote: post #497

Earlier quoted context omitted.

It's a Prisoners's Dilemma. Since apps are evaluated in an isolated fashion there is an incentive to use all the resources available to appear as performant as possible. There is further incentive to be as feature-rich as possible to appeal to the biggest audience reachable. That this is detrimental to the overall outcome is not unfortunate.

There's not extra apparent performance in using Electron. A truly more performant solution will be still more performant under load from other applications.

The extra performance is on the side of the developers of the app. They can use a technology they already know (the web stack) instead of learning a new one (e.g Rust) or hiring somebody that knows it.

Re: Zed on Linux Is Here

#555

Post by pilif »

doublerabbit wrote: post #535
pilif wrote: post #457

Earlier quoted context omitted.

True, but where's the difference between downloading a binary and executing it vs. downloading a script and executing that which will then download a binary and execute it? In both cases, you trust the publisher and in both cases the publisher gets equal access to your machine. Oh - you mean you're downloading the source code, then audit it, then compile it and only then you run it? That's super great. That has saved…

> where's the difference between downloading a binary and executing it vs. downloading a script and executing The difference is that the attack vector of the shell script is an easier target. If someone was to be malicious; they could manipulate the script and inject some sort of payload in disguise. It's an easier vector to damage than say an compiled package. One that's less prone to being detected in that the scri…

If I were to serve a targeted exploit like this, I would certainly hide it in the binary and have the binary determine whether it's running in the targeted environment and then run the payload.

It's much, much easier to hide a malicious payload in a binary than an easily auditable shell-script. And it's much easier to make a decision of whether the payload should be enabled or not if you are already running on the local machine.

If you don't trust a publisher, you really can't run anything of theirs. Shell script or, especially, binary.

Re: Zed on Linux Is Here

#556

Post by lapphi »

foldr wrote: post #538
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 do not notice any difference between my 120Hz work MacBook Pro and my 60Hz home MacBook Air. I might notice if I did a side-by-side comparison and looked closely. But why would I?

60hz gives me a headache after a few hours, been like that since I was a kid.

Re: Zed on Linux Is Here

#557

Post by mkl »

jacekm wrote: post #340
BrandoElFollito wrote: post #313

Earlier quoted context omitted.

Pressing some key a few times in Windows highlights your cursor. I just can't remember what it was (Ctrl I think)

Yup, Ctrl twice.

Once works. It's an option you have to turn on: Settings > Mouse > Additional mouse options > Show location of pointer when I press the CTRL key.

Re: Zed on Linux Is Here

#558

Post by mokkol »

sauercrowd wrote: post #98

Cool to see a new editor in the arena with a lot of resources behind it, but I'm trying to find the selling point besides "it's really quick". Great feature but there's a lot more stuff I need for a truly outstanding editor, what are the novel pieces? The bar is ridiculously for editors (vim & emacs configurability, vscode just works, jetbrains can do it all) - what will/does it bring to the table to compete?

I'm using Zed for a couple of months now. As a Vim bindings user, my personal fav Zed feature is that the Vim bindings really work.

Zed is made by people who used Vim themselves.

Re: Zed on Linux Is Here

#559

Post by gsck »

paride5745 wrote: post #448
dinozarw wrote: post #445

> To install Zed on most Linux distributions, run the shell script below. > curl https://zed.dev/install.sh | sh Please stop telling people to curl pipe scripts into their shell...

Indeed! Just release a flatpak, even a snap. I’m not asking to support all distros. But at least one between flatpak and snap is enough to support pretty much all distros out there in a clean manner, not with curl | sh

Snap is never the answer. Every time I use snap I always get really sad, it could've been great but instead its incredibly slow. Like unusably slow

Re: Zed on Linux Is Here

#560

Post by Fluorescence »

veidr wrote: post #526
Fluorescence wrote: post #499

Earlier quoted context omitted.

Vscode is very snappy for me on less powerful machine Ryzen 3900 (Ubuntu, X-windows). I have a good experience running multiple instances, big workspaces and 70+ actively used extensions and even more that I selectively enable when I want them. It's only the MS C# support that behaves poorly for me (intentional sabotage?!). I wonder if you have some problem on your machine/setup? I'd investigate it - try some benchma…

I have that kind of fast, smooth experience with VS Code, too - but that is when I open my small hobby monorepo, or only when I don't leave it open all day. When I open a big work monorepo (250k files, maybe 10GB in size, or 200MB when you exclude all the node_modules and cache dirs, the slowness isn't instant but it becomes slow after "a while" — an hour, or two. I do actually regularly benchmark it and test with no…

> Eventually, even typing will lag or stutter. Quitting and restarting it brings it back to snappy-ish for a while.

Hmm. I've not experienced that. Something is leaking which can be identified/fixed. There are quick things you could do to narrow it down e.g. restart extension host or the language server or kill background node processes etc.

I generally have it running for weeks... although I do have to use "reload window" for my biggest/main workspace fairly often because rust-analyzer debugging gets screwed up and it's the quickest fix from a keyboard shortcut. I may be not seeing your issue for other reasons :)

FWIW I can recommend "reload window" because it only applies to the instance you have a problem with and restores more state than quit/restart e.g. your terminal windows and their content so it's not intrusive to your flow.

> but the fact that it takes an hour or two to repro makes that sort of too cumbersome to do

Yeah, I know what you mean. I now schedule time for "sharpening my tools" each day and making a deliberate effort to fix issues / create PRs for pain-points. I used to live with problems way too long because "I didn't have time". It's not a wall-clock productivity win.... but the intangibles about enjoying the tools more, less pain, feeling in control and learning from other projects are making me happy.

Post reply on HN