The Creators of the Atom Code Editor Open-Source Zed, Their New Rust-Based High-Performance Editor
The Creators of the Atom Code Editor Open-Source Zed, Their New Rust-Based High-Performance Editor
Nathan Sobo recently open-sourced Zed, a code editor that focuses on performance, integrates AI capabilities, and supports software teams’ collaboration out of the box. For performance, Zed leverages a Rust code base, multicore- and GPU-optimized code, with a custom Rust GUI framework. For collabora...
You're viewing a single thread.
I'll be watching this one. It looks nice. Please come to Linux. I do loves me my vim. I did not like setting it up as much as I thought I would to be an IDE. I'm sorry I was mean Zed.
I've been trying out Helix as of late. It's a bit different than vim, but I'm beginning to like it.
Helix's autocomplete is too bad for me to be able to like it
what do you mean? Helix uses LSP servers, usually the same ones used by Vim and VS Code.
were you using it without the LSP's installed? If you were, then you would only get completion based of the treesitter grammars, which would be very limited.
no, the autocomplete trigger is rly bad and triggers when moving the cursor around instead of when you actually type It's a documented problem and they are working on fixing it
Ah I see. I usually only move the cursor when in command mode, so that might be why I haven't noticed it. That's unfortunately an issue I've noticed in a lot of editors. In fact, because Zed is so fast, the auto completion is super obnoxious atm and constantly flashes at you while you type.
I know it's the intended way but I'm too much of a modal noob for that, I'm actually working on a non-modal editor for this reason that's similar to helix and fish philosophies
Yes, that was mean, because nobody is able to make another editor as powerful as vim.
Time will tell for sure, but helix is looking really good and once they have support for plugins I'm rather sure it will be a very, very powerful editor.
I don't think helix will ever catch up to a lot of vims lesser know features of which there are a lot. I think that's by design as well, I think that helix wants to have a smaller surface area than vim and for a lot of people that will be the right choice. I personaly use ex-commands for example, or the quickfixlist fairly often so for me I have a hard time imagining helix not feeling like a step down power-wise (as nice as multiple cursors are).
I was also disappointed not to have ex-commands, but I soon realized Helix's use of multiple cursors with commands that support regex can accomplish the same tasks in a way I found more intuitive. Definitely took a bit to get rid of my
:%s/new/old/gmuscle memory, but Helix's select command works very similarly and just as quickly.Quickfix commands on the other hand I never used. It seems Helix has some features such as jumping to diagnostics and errors, but it doesn't have the ability to do so automatically after running make like Vim does (afaik). I don't write much C, so I didn't know that feature existed to begin with.
Multiple cursors are a lot better than
:sfor you standard search and replace, unless you have a really big file at which point helix gets to slow (which isn't that common) but there are a lot of other stuff you can do with ex commands.I use
:makepretty often, vim ships with the ability to parse a lot of compiler/linter outputs out of the box so if you tell it which one with:compileryou get build errors in the quickfix list. I also use:grepa lot. You can do<space>/to grep in helix but I often find that I want to add command line options to only search in specific directories or for specific file types (we have a large codebase at work). Being able to filter results with:Cfilter, and being able to go back to old quickfix results with:colderis also really nice. Finally, you can use:cdoto apply ex commands to stuff you've matched in the quickfix list.As an example, if you get a build error because you've renamed a variable in one file but not the places it gets referenced in other files, you can
:maketo get the build errors in you quickfix list,:Cfilterto narrow it down to only that specific class of error if needed and then do:cdo s/oldName/newName/gto rename the variable in all places that cause errors. You can then go back to the list of all errors with:colderand handle other errors in another way if needed.I'll have to admit that I don't do this that often so honestly I wouldn't lose out on that much switching to helix (after it gets proper plugin support and someone makes a decent replacement for the fugitive git plugin) but I would feel less powerful not knowing that I have those tools up my sleave lol.
Those are some neat features. I hadn't heard of them when I was using Vim. Parsing the compiler output to go straight to the error is very cool. I definitely think plugin support will bring a lot of people to Helix. I don't currently have any features I'm waiting on, but I'm sure I'll find some plugins to make it even better once they're available.
VSCode has way more features than Vim. Including the ability to run Vim inside the IDE. Or Emacs.
Sais no-one that knows vim, thou it have a vi-like mode that is missing most advanced vi-trixs.