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.

P.s. I'm hoping to eat my words one day.

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).

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.

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).

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.

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.

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.

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.

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.

One time setup cost is a small factor in choosing an editor. Stability and ubiquity are more important IMO.

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.

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.

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'd say that those features are useful for source code editing, not text in general.

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.

Ergonomic keybindings would be a challenge though.

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 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.)

Sadly, that achievement is compromised by having to call into unsafe code.

As long as the content of those blocks has been carefully checked there is no problem with using unsafe.

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.

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)

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.

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?

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".

I agree with you in principle, but in practice I’m not convinced this is an insurmountable hurdle for other editors.

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.

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.

I assume helix will be constantly evolving those ten or twenty years.

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.

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.

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 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.

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.

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.

https://www.farah.cl/Keyboardery/A-Visual-Comparison-of-Diff...

And for me I'm pretty sure that this "remap everything and translate every tutorial" barrier is why I never have been able to get into vim.

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 ).

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.

Here's a photo of the layout: https://image.shutterstock.com/shutterstock/photos/279261125...

As an Argentinian, I've no fucking idea why we have our own layout instead of just using ISO Spanish.

It doesn't look terrible, but believe me, switching to US English International was a one-way trip.

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..

Usually I have between 10 and 20 tab opened, so the tablist is very helpful for navigating between tabs.

Unfortunately (AFAIK) the 'fast' editors (vim, kakoune, etc) don't provide such feature. Some have a tree list but not a tab list :-(

Edit: sorry, it’s actually :ls

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

    vim: $
    helix: gl

    vim: D
    helix: vgld or t<ret>d

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.

[0] https://github.com/helix-editor/helix/wiki/Migrating-from-Vi...

https://github.com/LGUG2Z/helix-vim/blob/master/config.toml

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).

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.

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 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.

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).

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.

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.

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.

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.

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.

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.

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.

Ah, this old chestnut.

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.

Even that is a fairly new development. For a very time long 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.

Well..you just made the argument to stick to Neovim which already does this.