I fully expect Helix to replace Vim, Neovim, and Kakoune for most users in the long run.
Helix is built from the ground up around Tree-Sitter and LSP. This means you get the best syntax highlighting available, and IDE-like functionality, with zero configuration required other than installing the appropriate language server.
Those are by far the most important features for a text editor to have, and crucially, they are fully integrated into Helix, but are an afterthought in (Neo)vim and Kakoune. The quality difference is obvious the moment you try it side by side. Nothing else really matters. Vim's and Kakoune's syntax highlighting is terrible, and while Neovim can now use Tree-Sitter as well, there always seem to be some additional hoops the user needs to jump through in order to get it to work. Not so with Helix.
Regrettably, Helix has inherited Vim's worst design flaw, namely being unusable with non-English keyboard layouts, but all other Vim derivatives share this flaw as well so I don't see that stopping Helix from steamrolling the competition once it matures and the word spreads.
I just can't see if ever taking off, if I'm honest. The people that use neo/vim are going to continue using it, even if Helix is better. The people who aren't yet using it will use vs-code and the few that do switch, well they might go to Helix but there's a lot of vim resources out there, so I'm not sure all of them will go to Helix.
Honestly, language servers are a bit of a faff to set up, but that's tooling and it's getting easier and easier to get these installed now. I expect that will continue.
I've tried to make the switch to Neovim from Vscodium before but there was so much configuration for all the language stuff (and I'm not the biggest fan of Lua). But after seeing this post and installing Helix it's been pretty painless so far and I think this can actually help me make the switch. I am about to try some configuration for Rust debugging but that shouldn't be needed once they've got full DAP support. I use Neovim as my standard text editor so the navigation and bindings aren't a problem, lets see if Helix can make my IDE be in the terminal too.
For the longest time I was using YouCompleteMe with vim and then tried all sorts of LSP servers. And while I'm still using them, I feel like that YouCompleteMe solution back in the day had a lot less fiddling involved. Sure they have more features and more selection and variety nowadays, but I have spent so much more time configuring things that I kinda regret it now.
> I just can't see if ever taking off, if I'm honest. The people that use neo/vim are going to continue using it, even if Helix is better.
I would think that helix probably is better because I'm certain that the verb->text object paradigm in vim could be much better. It may in fact make more sense to do the 'text object' first like it seems to do in both helix and kakoune. But is it better enough for me to switch off something that I've used for years now? Only if it sees mass adoption and you see many developers adopting it. Like if you see it in VS Code as an option to use helix bindings, then it is probably safe to consider adopting it.
> Honestly, language servers are a bit of a faff to set up, but that's tooling and it's getting easier and easier to get these installed now. I expect that will continue.
I've been pleasantly surprised with how much better LSP setup in neovim has gotten, as I've transitioned over to the native LSP from CoC, which is also excellent. It's still not pain-free to setup, but it's much easier than it was and I suspect you're right that it'll continue to get easier... though I doubt it'll get anywhere close to how easy VS Code is to use any time soon.
While I was going through the effort to set up DAP support, I discovered [mason.nvim](https://github.com/williamboman/mason.nvim) which has been a game-changer for LSP, DAP, and linter setups.
There had previously been fragmented plugins (williamboman/nvim-lsp-installer was Mason's predecessor and is a good example) that solved the problem of installation and management for each of these. With Mason, I feel that the story for managing different language environments has jumped to be extremely close to VSCode's extensions.
> The people that use neo/vim are going to continue using it, even if Helix is better. The people who aren't yet using it will use vs-code and the few that do switch
I'm not so sure. I have been using vim for years and I still do, but in the last few years the majority of my use has been vscode with the vim plugin. I have seen the same pattern in many others.
Helix is right up my alley and I'm definitely playing with it. It's not a straight vim replacement for many reasons and it's also not yet a vscode replacement for me, but I'm very excited about it and I can absolutely see it replacing my use of vim sooner or later.
I fully expect Helix to replace Vim, Neovim, and Kakoune for most users in the long run.
Yeah, that’s not going to happen.
It’s cool to have choices, but you wouldn’t be the first person to think a new editor is going to replace Vim/Neovim. Vim is literally on every Unix/Linux server; every sysadmin can count on it being there.
I’ve been super impressed with the progress of Neovim and the team behind it. It’s only at version 0.8 but they’ve done some amazing things already.
I expect Neovim will get to the “batteries included” stage with Treesitter and LSP; it’s not far from there right now. And there are several Neovim distributions (LunarVim, Nvchad, etc.) that have all of the bells and whistles included. Helix sounds like it’s similar to one of these Neovim distributions.
Again, Neovim gives you choices: you can configure and tweak it to your heart’s content if you want or you can get something pre-configured with all the goodies installed and configured. Or you can use it headless from a different frontend (VS Code, browser, etc.) if that’s what’s needed.
Perhaps the best thing about Neovim is how great it is for both longtime Vim/Vi users and brand new users who are ready to graduate from Notepad and Nano.
>>And there are several Neovim distributions (LunarVim, Nvchad, etc.) that have all of the bells and whistles included.
Problem with distributions is as the contributions decrease they start becoming abandonware with time.
Leaving you with with vim and having to work through the configuration hell on the long term for yourself.
>>Again, Neovim gives you choices: you can configure and tweak it to your heart’s content
Trust me this is negative thing, not exactly something most programmers want. Most programmers don't enjoy configuring their IDE/Editors as a full time project together with your regular day job.
I agree with this. I spend most of my days on newly created systems (AWS EC2 instances) that are bone stock. I don't use any vim plugins at all because they wouldn't be the same everywhere and it's not worth configuring a system I'll only use for 2 hours. If I could get a full featured IDE installed by default on my systems I would ditch vim in a heartbeat.
You might want to look into Emacs with evil mode and TRAMP. TRAMP lets you remotely access files on a remote machine as if Emacs were running on that machine with all its IDE bells and whistles. It does require LSP programs and such to be on the remote side but you could probably script bootstrapping whatever you need fairly quickly. Certainly less setup than bringing over a whole editing environment with plugins, .vimrc, etc..
but you wouldn’t be the first person to think a new editor is going to replace Vim/Neovim. Vim is literally on every Unix/Linux server; every sysadmin can count on it being there.
Even that is a new(ish) development. For a long time people where saying exactly that about vim. I'm not _that_ old, and I was told early in my career not to get too dependent on either vim or the GNU tools since they probably won't be installed on most systems you connect to.
I don't disagree with your overall point, but that audience is pretty small, and the number of people who text edit a lot that a) need to float between machines frequently AND b) don't have enough access to install what they want is even smaller.
> Those are by far the most important features for a text editor to have
To you, maybe. The most important features of an editor for me, and for many people, is that it is stable, dependable, and ubiquitous.
There is no way I am going to re-learn years of muscle memory for a "post-modern" editor. Cool and trendy is the exact opposite of what I want in my tools. What happens with the authors get bored and move on to the next shiny thing?
Vim is available on ~every machine I could possibly interact with. There is a vim mode in every single mainstream editor / IDE. My Vim muscle memory will keep me productive for the rest of my life.
IMO, making something slightly nicer to configure is never going to overcome the inertia of a project like Vim. The new editor would have to be like 3x better to convince everyone to make the switch, not 1.1x better in some specific areas.
> Vim is available on ~every machine I could possibly interact with.
This is my exact reasoning for sticking with Vim. I use Neovim on my desktop, but I work with servers and have a homelab where I just want the greatest common factor. Nano is also an option, but just like you, my Vim muscle memory is embedded and I end up with :wq everywhere.
Is Helix cool? Absolutely. Will it replace [Neo]Vim? Not until it's installed by default everywhere, and that won't happen unless it has a compatibility mode for Vim shortcuts.
Exactly. The features OP described are IDE like features that many vim users like myself don't want in my basic text editor. Adding extra features via plugins is not an afterthought but design. He clearly doesn't understand the vim/neovim crowd and the design philosophy.
Small correction though, vi is available on every machine, not vim. But indeed this is big reason why I use vim for my own stuff.
Do you have any specific examples of things helix does better than neovim?
I think the neovim implementation of LSP and treesitter is quite nice. It was not that polished when I tried it last, but I think once it becomes mature, it will be really flexible. Tree sitter specifically is still considered experimental, but I think the timeline for that to be better integrated will be significantly faster than it takes for any new editor to get a decently sized community around it.
The zero config part of it is nice, but I think you’d be competing with e.g. VSCode with modal bindings on that note. Vim/Neovim have always had a fairly steep learning curve, and I can’t see that aspect of it mattering as significantly, especially since I only see LSP/Treesitter support improving in neovim.
There's a difference between having a "learning curve" and having to spend effort setting up things that work out of the box in another editor.
Vim advocates generally claim that investing time learning the Vim keybindings pays off as saved time during later work. But that's not what's happening here. If LSP just works in Helix, and requires fiddling with config files in Neovim, then Neovim is wasting my time, not teaching me something that will be valuable later on.
Yeah, learning curve may not be the best way to phrase it. But I think that is the price of flexibility to be able to create an editor in which you don’t have to use LSP if you don’t want to.
Personally, I think keeping Neovim the editor separate from something like nvim-lspconfig is pretty nice right now, to be able to update them separately, which is nice for new languages and language server changes. Maybe it (and the broader LSP ecosystem) will eventually be mature enough to be included by default.
I’d also say that if you want zero config, just using a config framework (there are a few), gets you most of the way there, whilst retaining more of the flexibility but that’s not a strong point in favour of Neovim.
Still, until Helix gets a comparable community and some features over a properly configured neovim, I think it will be hard to displace it (and Vim, EMacs etc.) because Helix doesn’t currently doesn’t as anything significant for existing users.
Any sufficiently complex "one-time setup cost" quickly becomes an ongoing maintenance quagmire. And I say that as a full-time neovim user for the past seven years.
Neovim is still my favorite vi, but I think I erred when I started bolting on so many plugins and supporting processes... when I want a lightweight IDE, I'll use VS Code.
> One time setup cost is a small factor in choosing an editor.
Perhaps for you, but empirically for devs as a population, this is very clearly false. A large part of the reason for VSCode's near-takeover for new devs in the last few years is its frictionless setup for almost everything.
Sometimes treesitter has problems. Indenting has gotten worse and configuration is a lot more complex.
I have the same config with some neovim / vim specifics and I find myself using vim more often even though the neovim features are "cooler".
I wonder if it will ever become "mature". It doesn't crash for that matter, but you have to keep everything updated constantly. Vim doesn't really have that problem.
Helix looks cool too, but I was looking for what it has that the others don't have and I can't figure it out. The website just makes it seem like it's cooler than the others.
Treesitter is still a bit iffy. LSP is a bit better, but is still not amazingly mature (but some of this is to do with the LSP servers themselves not being that mature).
Other than that, I haven’t had any problems with Neovim. Everything else has been rock solid, and I haven’t needed to update frequently for anything else. Have you experienced other issues?
However, these are the larger “killer” features of neovim, so at this point there’s not that much over Vim. However, there aren’t any Vim features I use that are missing in Neovim either. There are a couple of minor things that push Neovim over though (`inccommand`, Lua is marginally nicer, Neovim plugin scene has exploded recently).
So since Neovim (for me) has feature parity and equal reliability, with some really nice added frills and some moderately reliable, but maybe not incredibly mature, killer features it still beats Vim in my book.
For me personally is better because it works out of the box and their built in features are most of the things I need, fuzzy finder for files in the project, opened buffers, LSP, syntax highlight, etc.
If you are an old vim/nvim user, you already know deeply your editor/ecosystem and your config file is very solid, you definitely won't like helix at least yet, you need to learn to do everything the helix way and not the vim/nvim customised way you build all those years.
So I will say that for developers that are starting using terminal editors, helix is a very good starting point, because of the built in stuff that it seems essential at this point in time for an editor to already have and that might be what helix does better.
> I fully expect Helix to replace Vim, Neovim, and Kakoune for most users in the long run.
I hope this doesn't come off as flippant: I thought your comment was sarcastic at first.
While I love seeing newer / better software displacing the old and crusty, this seems a little unlikely, no? It seems like somewhat of a miracle that neovim has taken as much share as it has.
> It seems like somewhat of a miracle that neovim has taken as much share as it has.
It's not a miracle but rather a testament to how much Neovim improves upon Vim. The number of useful features, among them Tree-Sitter and LSP, that Neovim has introduced has ended what feels like decades of stagnation in Vim development.
Now imagine an editor like Neovim, but instead of working through 30 years of cruft and legacy code, it's built from the start using modern software engineering techniques and incorporates such features into its core editing model. That's essentially what Helix is. The Vim -> Neovim improvement is nothing compared to what Helix will deliver (and already is delivering in many aspects).
> Now imagine an editor like Neovim, but instead of working through 30 years of cruft and legacy code, it's built from the start using modern software engineering techniques and incorporates such features into its core editing model.
User inertia is strong. Neovim has its success because of its improvement, but more importantly, the keymap and config language is based on Vim7. Vim7 users can painlessly switch to Neovim with all config preserved. That's the main reason why Neovim can gain a large number of users initially. Conversely, Helix has no keymap nor configuration compatibility with Vim or other mainstream editors. Given this, I see no hope that Helix will become mainstream.
Based on my observation of colleagues' dominant usage of IntelliJ-originated editors, I think that modal-editors users are far enough from the mainstream that some rules dont apply: Heliy may end up dominant in our pocket-universe, based on merit alone.
IMO it is not that surprising that neovim has had some success, in the same way that it isn't very surprising that SwayWM has had some success. They both have the benefit of, in many cases, being completely compatible with the tool they want to replace. Being almost completely compatible with the old tool, while integrating a popular new technology (LSP or wayland) seems to be the only way to win over users who already have a strong connection to their tools of choice.
My vimrc already has a bunch of configuration in it, I'll give Helix a try when it is able to parse that (so, probably never, I guess).
> Those are by far the most important features for a text editor to have
The most important feature of a text editor is that it can edit text well. Vim is popular because it’s the best _text editor_ not because it has a bunch of plugins making it an IDE.
Code is text. So it is good to have a very good text editor for manipulating it as text. But code is also very different from plain text. It is highly structured. When I think about code I think about it as some kind of syntax tree (call hierarchies etc) . I don't think about it as character buffers. So if I am programming and I can have something that supports good text editing but also good tree editing then I will take that over something that only does good text editing.
I agree with this. I have never been a vim/neovim/helix user, so there's little I can contribute here. But I have always used paredit commands as much as possible, in all languages, not just lisps, and that's still true now that I've switched to vscode from emacs. I'm curious whether any vim/helix editing operations are "tree-based" in a similar way to paredit, and also whether anyone's building a paredit-like editing system based on treesitter.
I don't see it. If you want IDE features in a text editor, you can use VSCode, it even has vim bindings that are at least trying (with middling success) to match the originals. The addressable market for Helix seems to be (neo)vim users who aren't picky about keybindings and new users who want a terminal editor in 2022. So... on the bright side the developers can probably have one-to-one conversations with all 10 of these people.
I think you're overestimating the likelihood that Tree-sitter is going to gain enough traction to be reliable for general purpose text editing. It's great for popular modern languages, but not for everything, and there's no fallback in Helix. I'm not convinced that's ever going to change.
Reliable? I trust Tree-Sitter's grammars a hundred times more than the underspecified regex monstrosities that power highlighting in other editors.
Tree-Sitter grammars are unit tested, have usable primitives for precedence and associativity, and are generally far more predictable than previous highlighting systems.
Also, name a language for which there is no Tree-Sitter grammar yet. The only remaining ones are so obscure that the missing "fallback" is irrelevant for 99% of users.
Python, Janet, Haskell, and Hare were the filetypes I remember either being unsupported or not working well. I need to be able to depend on basic language support from my text editor, even when I work with niche languages.
I've been using Python with tree-sitter on neovim for many months. It's great, and has a lot of improvements when compared with the old syntax system.
Re Hare: I haven't even set that one up. Setting up a new tree-sitter on neovim requires extra work for each tree-sitter, and that's definitely a flaw that needs to be addressed.
> Helix is built from the ground up around Tree-Sitter and LSP
And what happens in ten or twenty years, when both are obsolete? I don't really care, what technologies my text editor is built on top of, but I sure would like to be able to still use it for writing my memoirs when I'm old.
LSP will not become obsolete, it will evolve. The entire industry is rallying around LSP, and Microsoft is constantly improving the protocol. In "ten or twenty years" LSP will have become a required feature for every programming language and every text editor. It will be essentially impossible to replace it with any other technology because of the massive investment already made in the ecosystem.
I can imagine Tree-Sitter slowly losing importance because LSP is integrating semantic highlighting, but Tree-Sitter will still be an easy option for writing grammars in the absence of a full-featured language server.
Unless the protocol changes to specifically address this, I find it unlikely that LSP will ever be a full solution for real-time syntax highlighting. The amount of JSON that has to be slung interprocess on each edit is just too much. Providing extra semantic highlighting on top of a built in option, absolutely, but I don't think it can replace an in-process, specifically incremental option like Tree-sitter or Sublime/TextMate language defs (or a completely custom solution like JetBrains, Nova, etc.).
I can see Helix replacing Vim and Neovim for the most "normal" user. It's great, and it's a better alternative than VSCode for Vim users that aren't quite power users but also not exactly the most basic user either.
However, until I can fire up a new installation of *nix and type `helix` to begin editing things it will never replace good 'ole Vim.
I'd say that has been true in the past (and is still mostly true today), but I think this will change in the future. I have been using lsp+treesitter for markdown editing and it's been an excellent experience. It's still early days, but with treesitter and lsp being as universal as they are I've been seeing a lot of people just experimenting with what's possible.
So yes, they are essential only for source code editing, but it's quite exciting to see what they can do for general text editing.
I'd say the most important thing is jumping to definitions. That's not terribly useful for standalone documents, but I use markdown for general note taking and it allows me to easily link other relevant notes. With that come a bunch of benefits, like autocomplete, finding all references, renaming/refactoring, hover preview, etc.
Other editors implement this specifically for markdown (i.e. Obsidian), but not needing to switch programs, as well as just having one set of motions/keyboard shortcuts has made a big difference in workflow for me.
There are also a lot of other surprising benefits of treating raw text the same as code. I started using auto-completion with user defined snippets when writing Documentation (makes it much faster to integrate code blocks, tables, etc).
Many (if not all) of these things can be done in other ways, but I think it all just fits very well together and I enjoy that workflow tremendously.
I'm looking forward to seeing Org Mode implemented as a language server. It's unfortunate that such a great general text organization tool is locked into the relatively small Emacs user community.
orgmode is so not a markup language and cant be served via lsp. its a whole ecosystem built on top of emacs. short of rewriting it, implementing it fully in another editor would require a sort of virtual emacs machine running in the background
Typescript or Rust are also not markup languages, and language servers for them allow for many interesting, non-trivial operations, so the model is capable.
Ergonomic keybindings would be a challenge though.
LSP goes far beyond source code. It also covers an increasing number of markup and configuration languages, and there are even language servers for prose that perform grammar checking and offer style suggestions.
Problem is, all of that sounds like a lot of crap to have running, and a lot of dependencies. That is not everyone's thing.
I like to be able to type "ps" and see one process for my editing session (with a low VM footprint in the low double digit megabytes at most, which had a startup time in the low hundreds of milliseconds.)
The existence of multiple editors of varying ages still in use today shows that tool choice is not a hard and fast X > Y thing. This personal choice is multi faceted and complex.
In software engineering, the proliferation of OSS is at the heart of what makes this craft great. Many passionate people create and recreate tools for the same “job”. All this happens with strong pressure towards public, inclusive and open communities around them. The fact that the method and medium require the same general skills means we can think very deeply about tool choice.
> I fully expect Helix to replace Vim, Neovim, and Kakoune for most users in the long run.
I feel like I am definitely not in the "most users" group here.
> syntax highlighting ... IDE-like functionality
> Those are by far the most important features for a text editor to have.
The most important features for me are the ability to navigate around and manipulate whatever's in the buffer(s) efficiently. I'm a 30 year vi/elvis/vim user and ... I'm not going to be able to use this. The deviations from vim's keybindings are much too widespread and tbh I find improved syntax highlighting and (especially) IDE-like functionality significantly too weak a draw to invest any effort in learning the Helix way - only to context switch between local Helix and remote vi(m) throughout my day anyway.
I tried, really I did. Opened up a file I'm actively working on. First thing I needed was `dd` and to my horror it didn't delete a line, but two characters. Turns out vim's `x` is Helix's `d` - except not quite; `5d` doesn't do what `5x` did, in fact the 5 does ... nothing?
OK fine, well, I regularly use `V` to highlight groups lines and delete those (or pipe them through my equalprg, or `:'<,'>!`) so I tried that ... nope. Though imagine my surprise when I tried `5x` and it highlighted 5 lines. Why didn't 5 apply to `d` but did to `x`?
I tried `:r!<some cmd>` but alas, no `:r` and in fact no `:!`. All these examples are things I do tons of times every day. So I read the "Migrating from vim"[0] document really hoping there was a "activate vim compatibility mode" thing but instead all I saw were the new sequences I'd need to learn, especially ones which require more keypresses such as:
go to line first non-blank character:
vim: ^
helix: gs
go to line end:
vim: $
helix: gl
delete to line end:
vim: D
helix: vgld or t<ret>d
Investigating more, I found `:insert-output` is the same as `:r!` - tried to map the latter to the former to no avail. I kept finding other things that pissed me off just while I was editing the config file (with helix itself). I want to turn off all the menus which pop up everywhere as soon as I hit `:`. I hated that every time I typed a double quote, it inserted two - I literally never want that, in any language, ever.
So many showstoppers for me, which is a shame. Perhaps I could configure the hell out of it - going against what many other folk are proclaiming as sensible, sane defaults - but then I'm back to where I came in. All the effort to make it be like vim except with some syntax stuff I don't really need... no sale.
I think most of the "muscle memory" bindings there are a bad idea (helix is different from vim - if you don't want that, I recommend neovim).
As for "dd" - that would be (as indicated in your quote) select line, delete (yd) in neovim.
Similar for delete to end-of-line - the second form is probably the "most helix like" - in being somewhat discoverable and "interactive" v(isual mark) return (end of line) d(elete).
As for filtering selection through pipe, or reading command output - they are also different:
"!" in normal mode is "insert-output" (r! in vim), while pipe is "filter" -
eg, after selecting three lines, hit "|" then input "sort<enter>" - and the selection is piped through sort.
As a long time vim user I agree that helix is alien - but I also think the change to selection-action is good for discoverability (the <space> context menu, interactive feedback on multiple replace) - and makes more sense.
I still would like to see <leader>, and some "shortcuts" like "dd" (but I'm not sure what would be "best fit" in the world of helix for that. I don't think "dd" is a great choice.
Thanks, I may give Helix another spin with that config. I saw the note about it being necessary to recompile, which I can't be bothered to do so I guess I won't get everything but it may get me through most of the day with less frustration (especially now I've turned mouse support off too; the cursor moving when I click to raise my terminal window was incredibly frustrating).
Two out of three examples for sequences that you provide are not shorter in vim.
At least on my (US) keyboard, typing `^` takes two key presses (Shift + 6), as does typing `gs`. The same is true for typing `$` (Shift + 4) and `gl`.
When reading the migration guide as a decade long vim user, I actually found myself to think that some sequences in Helix are improvements over the ones in vim. For instance, `gs` is easier than `^` because both g and s are on the home row.
I do agree that going from `D` to `vgld` is a big change. If it is consistent throughout the UX, it might not be that big of a deal, though.
I don't think I'd agree that two simultaneous keypresses is equivalent to two in sequence. But besides which, `^` and `$` are so ingrained with meaning to this grumpy old Perl coder that abandoning them is an extremely hard sell. Perhaps I'd be OK with `\A` and `\z`.
> I fully expect Helix to replace Vim, Neovim, and Kakoune for most users in the long run.
Is there anything preventing other editors from integrating LSP and making it work out of the box without any configuration other than adding a language server?
What's preventing it is their existing codebases, mostly.
IIRC, one of the first things Neovim did was throw out literally tens of thousands of lines of legacy code from Vim.
Meanwhile, Helix can just add the `lsp-types` crate as a dependency and they're already a quarter of the way to making LSP work.
The difference between adding something to a 30-year-old C project and a new Rust project is so massive that it can actually be the difference between "fairly straightforward" and "essentially impossible".
Right, but Neovim does in fact have LSP support. That part is done, that's not a blocker for the It Just Works experience. It's that the editor currently doesn't come with the relevant configuration (in vimscript or lua).
While the Mac-only editor BBEdit isn’t open source, it is a 30-year-old C++/Objective-C project, and BBEdit 14 added LSP support which is largely exactly what the comment you’re replying to suggested: install a language server somewhere on your path and BBEdit will find it and use it. It’s preconfigured for a couple dozen popular ones, and adding ones it doesn’t know about out of the box is usually just as as easy as filling in a couple fields in a dialog box.
I agree with you in principle, but in practice I’m not convinced this is an insurmountable hurdle for other editors.
> Regrettably, Helix has inherited Vim's worst design flaw, namely being unusable with non-English keyboard layouts
How so? I find the default helix shorcuts to be generally quite close to "ascii text input" - that is: ctrl, shift, alt, a-z and regular punctation?
FWIW I work on a Norwegian layout on a Mac, which is rather horrible for programming and shell use (option-7 for pipe, shift-option-k+space for tilde (!?), shift-option-7 for backslash, shift/option/alt + 8,9 for brackets ...).
I do miss "leader" from vim/neovim - and autocompletion from buffer (when there is no language support, like configuration files).
> How so? I find the default helix shorcuts to be generally quite close to "ascii text input" - that is: ctrl, shift, alt, a-z and regular punctation?
Try it with a non-Latin script language. It's borderline unusable.
Nothing works in Normal mode. You have to manually switch back to English any time you switch to Normal mode and back to the other language in Insert/Replace mode, or when typing parameters to things like :s.
No other editor requires you to switch language back and forth just to use the editor's commands.
If find motions in neovim a lot easier to reason about than those in helix. A lot of actions that are pretty easy on neovim are a huge pain on helix.
I do appreciate Helix as a research project investing in new ideas, but I do feel it a lot more limited. Everything keyboard/motions related just feels much more limited than Vim. For example, re-doing actions makes little to no sense because most actions tend to be split in two. `3dw` can be redone just fine on neovim, but not on Helix.
Can someone elaborate on why Vim doesn’t work well on non-english keyboards.
I use Vim occasionally using a Nordic layout but would like to know why English is superior.
On a Latinamerican keyboard (yet, that's a thing), the brances are not as convenient. IIRC, the ~ symbol isn't even around. Semicolon is shift+right right finger -- super odd compared to just pinky. And ^ is behind right-alt (the one in the photos shows where, but many don't actually have it printed on the keycap).
I'm a nordic-layout user as well and whenever I look at the actual differences side-by-side I get reminded about how much easier it would be to code if I had all those symbols that close.
I grew up with the Icelandic layout. When I started programming professionally I taught myself the en-us layout and stared using that instead. It is much easier on my hands and fingers; it really does show that the people who came up with the syntax for most of the programming languages in use picked things that were easy to type on a US layout and didn't give any thought to the rest of us.
I’d love to know what the result might have been if they gave some thought to the rest of you. And if a person is designing a programming language syntax, I don’t see why keyboards that are foreign, even unknown, to them merit much consideration.
BTW I really don’t think the en-us layout is actually nice on hands and fingers. All the programming symbols are a stretch. I now use Karabiner to make easy key-chords for all the symbols, e.g. f-j is ( and f-k is ).
I do not think there's a particularly feasible way to facilitate every keyboard layout out there, so it makes sense that they are at least built with one keyboard layout in mind, much like I think it makes sense that programming in general is overwhelmingly done in English. It increases interoperability significantly.
I tried that once, but already back then my muscle memory wasn't having it. Now I'm too old to put down the required hours to relearn and get back up to speed.
Here's some advice from a Norwegian who programmed in Vim for years on the nordic layout: do yourself a favor and get an American keyboard ASAP. The brackets alone are worth it.
It's really not, so long as you map hjkl to the appropriate key sequence on your keyboard. Everything else is based on mnemonics, not locations, so I is just I.
Maybe some stuff might be quicker because it's on the first layer, but if it's so bad you can map those specific keys.
I like Helix, but it feels slow compared to Neovim. As in the actual scrolling performance. No one else has mentioned this, so I wonder if that’s an issue on my machine.
> Those are by far the most important features for a text editor to have
The most important feature of an IDE is to be easy to use, having powerful functionalities is important too, but that's goes after..
VSCode has nailed the first point.
Wake me up when (neo)vim/kakoune/Helix has a "list of tab view" similar to VSCode..
99% of my neovim usage is not programming, and either way I have never found syntax highlighting and similar to be all that important. Text editors need to view and edit text, and do it well. That's about it.
Have you checked what that unsafe code does? Unsafe code is not bad per se, there has been quite a bit of discussion about the naming of unsafe and many are of the opinion that it should have better been called something like trustme to clarify that the code must not be necessarily unsafe, just that the borrow checker doesn't fully check here, which for certain core algorithms can be necessary.
As long as the content of those blocks has been carefully checked there is no problem with using unsafe.
> just that the borrow checker doesn't fully check here
That's incorrect. The borrow checker performs the same checks inside `unsafe` blocks as everywhere else.
`unsafe` blocks can perhaps best be summarized as areas of code where memory safety rules are relaxed. The borrow checker deals with ownership, and ownership rules are still fully enforced inside `unsafe` constructs.
> just that the borrow checker doesn't fully check here, which for certain core algorithms can be necessary
Why is that? Does this imply that there are certain algorithms you simply can't write (efficiently) when using the borrow-checker? (I don't know Rust btw, but have plans to start learning very soon)
Missing some nuance, but that description is not too far off. The ownership/borrowing concept is based on the idea that every piece of data has a single owner. Particularly in cyclical data structures, it's not very clear who should have final ownership over what. This can make graph-like data structures somewhat difficult to express.
Helix is built from the ground up around Tree-Sitter and LSP. This means you get the best syntax highlighting available, and IDE-like functionality, with zero configuration required other than installing the appropriate language server.
Those are by far the most important features for a text editor to have, and crucially, they are fully integrated into Helix, but are an afterthought in (Neo)vim and Kakoune. The quality difference is obvious the moment you try it side by side. Nothing else really matters. Vim's and Kakoune's syntax highlighting is terrible, and while Neovim can now use Tree-Sitter as well, there always seem to be some additional hoops the user needs to jump through in order to get it to work. Not so with Helix.
Regrettably, Helix has inherited Vim's worst design flaw, namely being unusable with non-English keyboard layouts, but all other Vim derivatives share this flaw as well so I don't see that stopping Helix from steamrolling the competition once it matures and the word spreads.