Zed on Linux is out!

https://jlai.lu/post/8476122

Zed on Linux is out! - jlai.lu

Anyone care to compare this with Helix?
Zed has a lot more features and is GUI-based. Helix is more focused and is CLI-based. I think a more direct comparison would be with VSCode(ium).
Why Helix over (neo)Vim?
Better/simpler experience out of the box. With Helix you install the LSPs for languages you use and you’re set with a fully featured editor. Manual configuration is only needed for setting themes, keybinds, and small setting changes. It also feels much faster than a fully configured vim/neovim. Lastly its keybinds are inspired by Vim/Kakoune, but different from both.
A better out of the box experience-- fewer plugins required. More discussion here: urbanists.social/@markstos/112586854536602496
Mark Stosberg (@[email protected])

@[email protected] @[email protected] @[email protected] @[email protected] I previously posted an analysis of my Neovim plugins. I had 34 and all but about 4 were replaced by the out of the box #HelixEditor functionality. It’s not that I want extreme or exotic configuration, but that expectations have been raised for what’s considered basic functionality. Fuzzy finders, LSP language enabled, git integration all seem like things that shouldn’t require plugins now.

Urbanists.Social
Cool, but is it possible to add vim bindings to Helix? I’m too used to them, I even use them in Emacs.

A lot of the bindings are the same, because Helix was inspired in part by Vim.

Helix overall tries to make more consistent vocabulary and “nouns” and “verbs” in the keybindings, so there are some breaking changes.

Someone published a more “vim-like” set of keybindings for Helix: github.com/LGUG2Z/helix-vim

I started with that and then have slowly disabled a number of them as I come to appreciate the Helix defaults, and have realized that some of these vim-bindings are overriding other Helix bindings that I wanted.

GitHub - LGUG2Z/helix-vim: A Vim-like configuration for Helix

A Vim-like configuration for Helix. Contribute to LGUG2Z/helix-vim development by creating an account on GitHub.

GitHub
What’s that?
Integrated Development Environment (IDE) from the makers of Atom. It is written in rust.
Oh man I LOVED Atom. Giving this new one a test drive now :)
I think Zed is quite different from Atom. But Pulsar might be your thing. A direct fork of the last release of Atom being developed by ex Atom developers :)
I just mean that I liked the work that the devs did on Atom, which makes me want to try this one out too
Oh, in that case you might like either. I think both are great in their own way!
Just to clarify, the Pulsar devs aren’t ex-Atom devs. Some of the team are from atom-community but none of the core Pulsar team were part of the official Atom team.
Oh, interesting. In that case I misunderstood that part, I thought there were core devs of Atom involved in Pulsar, thanks :)
Watch this space for the full history, I’m literally putting the final touches on a blog post that will go into details of how Atom started then how it became Pulsar as a little celebration after we hit 3k stars.

Thanks. I briefly used Atom (on Win) but stopped as it was terribly slow to startup.

What is the software license for Zed? It’s Github page isn’t clear.

The code for Zed itself is available under a copyleft license to ensure any improvements will benefit the entire community (GPL for the editor, AGPL for server-side components). GPUI, the UI framework that powers Zed, is distributed under the Apache 2 license, so that you can use it to build high-performance desktop applications and distribute them under any license you choose. zed.dev/blog/zed-is-now-open-source>
Zed is now open source - Zed Blog

From the Zed Blog: We hope you'll join us in our mission to fundamentally advance software collaboration.

Zed is not an IDE, it's a code editor. No, they aren't the same things, it's like saying a table and a kitchen are the same thing.
You are right, stand corrected.
This distinction is not as meaningful as it used to be before LSPs; there’s little a PyCharm IDE can do that you can’t do in VS Code editor for example.
Interesting project, how ever it will be hard to compete with existing editors and its plugin eco-systems.
I don’t think so. The guys who wfite the plug ins are he cracks and the cracks will use zed.
It supports LSPs, and has treesitter syntax highlighting and git integration which honestly makes it 90% of the way there already
Vim keybindings or death

Installer is piping curl into shell

I thought we were past this as a society 😔

I mean its already in the nix repos as well as homebrew which means its essentially taken care of
I’ve been using it with the nix package manager. It’s awesome how easy nix works
It appears to be a couple of versions behind … and have some issues with dynamically linked libraries that hinder LSPs. Neither of these is Zed’s fault. I’m sure the packaged version will be up to date momentarily (given the interest in Zed, sooner rather than later). Not sure how easy the LSP thing will be to fix, though there are some workarounds in the github issue.

yeah the editor is being updated way too fast for nix to keep up. I’m sure it’ll be easier once it has its stable release. I see the have a nix flake in the repo, it would be great if they added a package to the outputs instead of just a devshell, nix users could easily build it from master or whichever tag they want.

There are solutions in this issue to the LSP issue. The editor would need to be built in an fhs-env, or they will need to find a way to make it uses binaries installed with nix instead of the ones it downloads itself. VSCode had a similar issue, so there is a version of the package that let’s you install extensions through nix, and another that uses an fhs-env that allows extensions to work out of the box.

zed-editor: 0.141.3 -> 0.142.6 by GaetanLepage · Pull Request #324549 · NixOS/nixpkgs

Description of changes Changelog: https://github.com/zed-industries/zed/releases/tag/v0.142.6 We need to wait for Rust 1.79. Things done Built on platform(s) x86_64-linux aarch64-linux x86_6...

GitHub
So it should say hey check your distros package repos first.
Yeah. Especially rather than saying “curl/bash” is the preferred way of installing.
There are various package manager vectors for installation listed in the docs

That was my first thought as well, but I will say that uBlue distros had a signing issue preventing updates recently, due to an oversight with how they rotated their image signing keys, and the easiest (maybe only?) solution was to pipe a curl command to sh. Even though uBlue is trustworthy, they still recommended inspecting the script, which was only a few lines of code.

In this case, though, I dunno why they don’t just package it as a flatpak or appimage or put it up on cargo.

Linux - Zed

ooh, available for “x86_65” on Alpine

(and they’ve fixed that now)

imagine the nightmare of writing a 65 bit instruction set

I don’t think it has to be a nightmare per se if you start from scratch.

Instead of 8-bit bytes, you have 5-bit “bytes” (fyves?) Hoozah! Done.

only if double precision can be called high fyves
This is a mandatory rule now.

Now imagine designing a 65 bit computer. The bus, registers, alu…

You’ll probably waste a lotta chips since most of them are designed for working with powers of 2

It’s a new architecture that’s a bit better than x64_64.

Finally. 65 bit processor.

Not until after you convince these projects to stop using discord
As long as they just use it for their community and don’t fucking lock documentation behind discord I don’t really care. But this trend has been so annoying. Due to this I’m in so many servers I have to quit a server just to join a new one

It is worrisome that all the smug elitists are too incompetent to just leave off the pipe and review from stdout, or redirect to a file for further analysis.

Same people will turn around and full throat the aur screaming ‘btw’ to anyone who dares look in their direction.

By that logic you have to review the Zed source code as well. Either you trust Zed devs or you don’t - decide! If you suspect their install script does something fishy, they could do it just as well as part of the editor. If you run their editor you execute their code, if you run the install script you execute their code - it’s the same thing.

Aur is worse because there usually somebody else writes the PKGBUILD, and then you have to either decide whether to trust that person as well, or be confident enough for vetting their work yourself.

Eh using aur packages is a bit different since most of# them pull the projects git repo directly anyway. Yeah the project might have vulns but thats on you to inspect before building it.
Can’t we basically call this a remote access trojan?
Security wise it doesn’t matter, you run the code they wrote in any case. So either trust them or don’t. Where it matters is making a mess on your computer and possibly leaving cruft behind when uninstalling. But packages are in the works, Arch even has it since before linux support was announced officially.
So did fedora and nix
This isn’t true because until the PR fixing it goes through it downloads other binaries without user consent.
I think you slipped in the discussion intendations somewhere, this branch of the discussion tree is about the implications of piping curl into bash vs. installing packages