Zed on Linux is out!
Zed on Linux is out!
@[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.
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.
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.
Installer is piping curl into shell
I thought we were past this as a society 😔
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.
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.
ooh, available for “x86_65” on Alpine
(and they’ve fixed that now)
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.
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
Finally. 65 bit processor.
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.