1. 70
  1. 23

    I’ve just tried Helix and I’m absolutely blown away by how good this is. I needed to rebind the hjkl to a sensible colemak equivalent like I always do (I wish editors would work on keys not characters. Some games know how to do that), but after that… everything is there, and it just works. Opened a Rust file, all the LSP support, all the sensible keybindings and checks… like in every modern IDE, you may say – and you’ll be right. But this is lightweight, starts instantly and has all the nice moving and editing capabilities – and with a kakoune-like grammar, which I find superior to vim’s, but kakoune was never quite there for me with all the IDE-like niceties.

    I can’t wait to try this at actual work tomorrow and see where it itches me. But my first impression is a 9/10.

    1. 8

      I wish editors would work on keys not characters

      As a Dvorak user, I wouldn’t be happy about this. When I think cw for “change word”, I’m definitely not thinking j,. hjkl are an exception that don’t really have a ‘word’ meaning they symbolize. I’ve just gotten used to it and with jk being more common to me and still next to one another on Dvorak, it’s tolerable.


      This is where it actually is problematic, where the keys are purely buttons and rarely are symbolic of anything else. Since I don’t change my key labels, it’s a quick, one-time setup to just press the matching key before I start a game and accessibility has been pushed pretty hard in recent times so all games published in serious are configurable.

      1. 2

        Hmm, good point. I remap hjkl to hnei, but I keep all the others and remember them because of the meanings (like word-change) that make them easy to remember.

        j-k on colemak becomes y-n on my keyboard, which is not very handy (and upside-down, logically). I still taught myself to use it, whenever I’m on vim that doesn’t have controls remapped.

        1. 2

          and upside-down, logically

          Indeed. One of the things I like about dvorak vs colemak is that many of the keys are also just fine for programming. eg. jk are right next to each other, hl are still logically left and right, dash/underscore is on the home row, etc.

          1. 2

            I really undervalued the home-row dash/underscore until I tried briefly an alternative layout. It’s such a common key for programming and normally gets placed in the most obtuse places – like number row on QWERTY.

      2. 3

        I wish editors would work on keys not characters.

        Sadly, terminal-based apps need to work with the input events that the terminal sends them, and the terminal only sends characters. Even GUI apps can wind up in this trap if they’re based-on or portable-to a terminal UI, like GVim for example.

        1. 1

          I guess i3 isn’t a terminal app, but I think when that’s initialized they remap everything if the layout is different. Someone correct me if I’m wrong here. … But maybe an editor could do the same? Just an idea.

          1. 4

            As a concrete example, when you press a key in your browser, the KeyboardEvent that gets fired has a [key] property that describes the letter typed, if any, as well as the code property that describes the physical location on the keyboard, as well as properties like shiftKey, ctrlKey, altKey, and metaKey that reflect whether that modifier was held down. So when I type a double-quote on my Dvorak keyboard layout, the key property is ", but the code property is “KeyQ” (because Dvorak puts the double-quote where QWERTY puts Q) and the shiftKey property is true.

            An app like i3 will look at the binding specified in the config file, consult the X11 keyboard layout extension to find out what code corresponds to that key, and then when a keyboard event arrives it checks the code rather than the key, and therefore works no matter what changes have occurred to your keyboard layout in the mean time.

            Meanwhile, when I type a double-quote in my terminal, the terminal receives byte 0x22, ASCII ". That’s it. No key code, just the key pressed. Even if there were a way to obtain the keycode of a key event, there’s no way to consult the keyboard layout configuration, so it wouldn’t be possible to transparently remap bindings.

        2. 2

          I wish editors would work on keys not characters. Some games know how to do that

          I think in general this should be avoided, because it makes documentation difficult. When character-based, you just document that ctrl+a does something, and no matter the layout or keyboard configuration anybody who has these two keys will be able to do just that. If it was key-based, an azerty keyboard user would have to know that this actually means pressing ctrl+q. This get much worse with non-alphanumeric symbols.

          With dvorak or colemak it might be ok since the user generally knows the american qwerty layout, but that’s definitely not the case for other layouts.

          As stated in another comments, games are indeed one of the only cases where I can see an argument being made for key-based bindings.

        3. 5

          What about Emacs?

          I don’t really know it well enough to speak to it. I’m open to running through a tutorial but I just never worked at a place where its use was widespread enough to justify sitting down and learning it. If there’s a good tutorial though hit me up on Twitter and I’m glad to run through it.

          No tutorial, but I can tell you my experience.

          With a few lines of configurations to enable rust-mode and eglot (the Emacs client that speaks to rust-analyzer), I have a very comfortable editing experience. I have the usual syntax highlighting, auto-indentation (plus cargo fmt on save if you want), jump-to-def, find-reference, etc. There’s limited refactoring support with a rename functionality, that I use maybe once a week. The only thing that’s annoying, but I’m not sure it’s an Emacs thing, is that switching from one branch to another causes rustc to recompile a bunch of things and the computer becomes slow for a while, with all the CPUs maxed out.

          1. 3

            I think LSP has done wonders for emacs, personally, Doing language analysis in the editor was a bad idea. I think tree-sitter is the logical next step of this: the editor should know how to display highlighted text, but it shouldn’t have to know the highlighting rules.

          2. 4

            ad sublime text in “You just need something right now”: it works very well on macos and windows too

            1. 4

              To add to the comment about Helix vs Vim on large files - I’ve found Helix’s tree-sitter to be very slow for large markdown files https://github.com/helix-editor/helix/issues/3072#issuecomment-1207319836

              1. 3

                To be fair, Helix uses the same tree-sitter library for markdown that Neovim uses, the one from MDeiml. So I’d assume that if Helix is experiencing slowness while opening large markdown files, so will Neovim.

                I’m sure tree-sitter has been a helpful tool for people but in my anecdotal experience, almost all the tree-sitter libraries I’ve used so far (HTML, CSS, shell scripts, markdown) are too buggy to be used as a daily driver.

                1. 2

                  I’m sure tree-sitter has been a helpful tool for people but in my anecdotal experience, almost all the tree-sitter libraries I’ve used so far (HTML, CSS, shell scripts, markdown) are too buggy to be used as a daily driver.

                  I’ve also had this experience. It’s not that I can’t use them, but there’s weird inconsistencies. For example, tree-sitter’s TypeScript TSX highlights components normally, but highlights regular elements like <p /> the same color as imports (for me it’s red, in Solarized Light, whereas components are normally highlighted blue), which is really odd and makes no sense to me. So now my render functions in React look like some kind of weird American Flag Tribute (never forget in 4 days) to TypeScript.

                  In terms of a “daily driver”, I still use Vim plugins like vim-javascript and vim-json for highlighting, but tree-sitter has allowed me to remove a ton of syntax highlighting plugins that I just don’t need to have hanging around, which has been beneficial. But yeah, wouldn’t say it’s ready to replace your entire syntax highlighting stuff.

                  1. 1

                    tree-sitter’s TypeScript TSX highlights components normally, but highlights regular elements like the same color as imports

                    This is very likely to be an issue with your colorscheme and not with tree-sitter/the grammar. I would be very surprised to hear that tree-sitter/the grammar gives your editor the same tokens for these two very syntactically different constructs.

                2. 2

                  That’s great feedback. Thanks for the link. I’ll test it.

                3. 3

                  I am in the Zed beta. It is extremely fast. It doesn’t quite have all the features I need for my daily driver, because I am mostly a web dev, but it’s close.

                  1. 1

                    I also got in the beta but I do not have Mac to test it on :( Wish it had Linux build

                  2. 3

                    What it seems to be doing is going through your file and changing the beginning of the word to be a two letter code that is unique. So you can very quickly jump to words. Now this would make sense if it prefixed the words with the characters, but on my installation it replaced the first two characters. This makes files pretty much impossible to work on.

                    I’m guessing it’s inspired by vim-sneak and easymotion? that would make sense with the overlays, since both were developed before vim had virtual text.

                    Minute to minute it does feel a lot like Vim, which for me is a huge perk but might not be for you. The basic flow is reversed though, so instead of action -> object it’s object -> action. To delete a word in Vim is dw, delete word. In Helix it is wd. There is a fair amount of muscle memory for me around this, so it isn’t an instant change. However the payoff is pretty massive.

                    Sounds like it was inspired by kakoune. It has that, along with being multiple-cursor-centric and having really helpful completions for g.

                    (This isn’t a mark against either language, I love it when things draw inspiration from other things and then put their own twist on it)

                    1. 2

                      Sounds like it was inspired by kakoune.

                      It was indeed. From the Helix website front page:

                      Multiple cursors as a core editing primitive, inspired by Kakoune.

                      And from the docs:

                      Helix’s editing model is strongly inspired from vim and kakoune, and a notable difference from vim (and the most striking similarity to kakoune) is that Helix follows the selection → action model

                    2. 3

                      whaaat! pepper (https://github.com/vamolessa/pepper) wasn’t mentioned :(

                      1. 2

                        It’ll be in the next one along with Zed and Micro.

                      2. 2

                        Not a tutorial but a pretty good presentation on using Emacs with evil mode for Vim users: https://www.youtube.com/watch?v=JWD1Fpdd4Pc

                        IIRC it’s actually a Emacs presentation to a Vim user group. So that’s interesting in itself.

                        1. 2

                          I’ve been using Helix on my Windows gaming rig when I need to edit something. I’m really impressed with it. I’m not quite ready to give up my Vim config but not far from trying it.

                          1. 2

                            I was hoping to see one that was easily extensible in Rust, both interactively, and via plugins and config files. But I guess that’s a big ask for a language like Rust.

                            For me, that’s the killer feature that keeps me on Emacs.

                            1. 6

                              Yeah, I think doing interactive Rust would be hard. If I was going to make something as customizable as emacs, I’d embed a scripting language. Maybe JS, maybe Lua.

                            2. 1

                              If someone says Rust text editor, I think https://makepad.dev/.

                              1. 1

                                Been using Zed for the past month and it’s awesome. It’s a shame the author didn’t test it. The post is very informative though 👍

                                1. 3

                                  I’d love to! Get me an invite!

                                  1. 2

                                    It sounds like an amazing project but since it is MacOS only so far and I’m on Linux only I can’t even give it a spin.

                                    1. 1

                                      DM’d on twitter