Notes on Switching to Helix From Vim

I genuinely don't like the concept of the keyboard interaction in helix and kakoune, selecting things to modify them. I don't know what it is, but it somehow just feels much less satisfactory to me personally compared to the vim way.

I don't have direct experience with either Helix or Kakoune but after only a few minutes tinkering around, I can see one big reason: In Helix, most of the basic commands seem to be the same as vi. Whereas I understand Kakoune inverts the action/movement paradigm of vi. Maybe that's a more sensible design, I don't know. I didn't check to see whether or not the key bindings were similar but at that point, it's rather moot.

I've been using vim for 25 years, my muscle memory isn't going to tolerate switching to a whole new text-editing "language" at this point. But I could perhaps learn to live with a new dialect.

Kakoune's problem is the bad UI (eg LSPs hover), and that scripting it is simply too complicated.

Aside from the other replies, marketing matters. This is the first I've heard of this thing which apparently dates to 2011.

This is unfortunately exactly why I never used (neo)vim or kakoune (or tbh, sublime text whose lsp integration I have never successfully gotten working). Going from school (Java + NetBeans/C# + Visual Studio) to work (C#/JS + Visual Studio -> C#/TS Visual Studio Code) I had expectations for certain language features being available by default. Helix is the first editor of its ilk to get configuration out of my way so I can effectively write code the way I'm used to.

I think the easy setup is exactly the reason Helix has taken off compared to Kakoune. It probably has the most simple onboarding experience I've had with any text editor. Things just make sense, and tools that should be built in are.

I think the philosophy of delaying the plugin system as long as possible is one of the reasons helix has achieved that.

With Helix I just have to learn selection first, and few different binds compared to vim. With Kakoune, I have to onboard into a more complex ecosystem, in addition to that. A lot of people already have vim/neovim config fatigue so that's not very compelling.

`ed` is in the spirit of teletypes. It's the editor of choice when all you have is a dumb text-based prompt with no control of full-screen display. The whole point of `vi` originally was to be a `vi`sual mode for `ex`, which is a more full-featured variety of `ed`.

It's not integrated at all right now. It's still sitting in a feature branch unfortunately.

Lisps make great configuration languages because of how dynamic they are. It's like Javascript on steroids. Redefine core symbols. Modify a syntax form and reevaluate all of your code so that it does one thing in one environment and something else in a different one. When building large software in a team this can be a big drag; learning some weird syntax form that a coworker merged in that you didn't review can be a headache and when everyone makes their own design patterns, the codebase becomes a mess.

But when you're just configuring software this heavily dynamic nature becomes a strength. I just need to build the abstractions in my config that I need, nobody else. It's easy to poke around in and spend a few minutes writing and iterating on code to get the config I want.

I agree that the prefix notation and the soup of parentheses give it a higher learning curve than something like Lua which is easily understandable if you have experience in pretty much any modern programming language. But it's not the mathematical/computational purity that makes Lisps appealing, it's their highly dynamic nature.

When someone is competent, as must be after using a tool for 20 years (not days). Expecting that someone to complain about a difficulty for something trivial is surprising. There are other ways to highlight that it is easier or simpler in Helix to have working LSP, for example, saying it is "as easy as in vscode". But it is definitely bewildering why would the OP choose to start by bragging of the vast experience, and then focus on a complaint that most people expect from someone who has very little experience.

I use both helix and vim every day. After a while your brain just adjusts. It's like playing on playstation and nintendo for a long time. Eventually as soon as your hands touch the controller it switches to the appropriate mode.

Where does evil-mode land?

the lack of a `gq` equivalent to reflow a paragraph, which julia mentioned, was the nail in the coffin for me when I tried it.

It's a nice project though, I just use that feature constantly

Because immediate visual feedback is more natural than having to imagine an operation in your head, it's the same logic for multiple cursors - where it's even harder to understand what "change this word" will actually change.

> why THAT of all things?

Because that's a fundamental improvement

There were a few blogs with more detailed explanations, not sure about Helix, but kakoune had it covered https://kakoune.org/why-kakoune/why-kakoune.html

> Kakoune tries hard to fix one of the big problems with the vi model: its lack of interactivity. Because of the verb followed by object grammar, vi changes are made in the dark, we don’t see their effect until the whole editing sentence is finished

Having separate commands for creating/modifying selections and for editing their contents is more orthogonal. In kakoune, you can select a word, multiple words, multiple search results, a brace-delimited block, or an arbitrary sequence of characters (it's pretty common that I want to include a bit of whitespace, or instance), and the same 'c' command works on all of them. The same 'd', 'i', and 'a' commands also work on all of them. In straight-line editing it's no more keystrokes than vim, and hardly more than any other editor, but for complex operations it lets you tailor and preview them as you go. The thing that confuses me is why it would even be a debate that this is better.

(for kakoune, not helix) i've used kakoune daily for almost 2 years now, and i still mix up e.g. `(?<!` vs `(?!<` for lookbehind regexes. i appreciate the ability to select a region and watch whether my regex has selected what i expect.

but, this is probably less important than the simplicity of the selection first model, as it ties into multisel, etc. a selection is a cursor and an anchor. other keys manipulate the selection(s) in very particular ways, which are predictable. external tools interface easily with the selection format, as it represents cursors and anchors.

each benefit taken alone is quite small, but together they offer kakoune a very lean, predictable design when combined with its use of external programs for tasks like sorts or paragraph reflows.

helix is similar to kakoune w.r.t. the editing model. kakoune has `w` to select the next word (and move the anchor to the start of the next word), and `W` to select the next word (and keep the anchor where it is, so you now have two words selected). helix has `v` to enter visual mode, which is essentially equivalent to caps lock with kakoune --- `vw` in helix is equivalent to `W` in kakoune (i believe).

i think selection first is better, but i think it's fair to prefer vim's style, obviously. but there's certainly ample reasoning, though helix might not explain it thoroughly, because (at least, at one point) they may have expected users to have viewed kakoune previously, and understand its philosophy, as helix is essentially a batteries-included kakoune (and kakoune explains the reasoning quite thoroughly).

Their cargo.lock file is 3500 lines or so: https://github.com/helix-editor/helix/blob/master/Cargo.lock

So, I kind of agree with you, but that’s still a lot of dependencies baked into the editor. It’s probably not as bad as Neovim+plugins, but it’s still a supply chain issue.

  305 with helix- removed
  258 with gix removed (git stuff in multiple packages from a single upstream group)
  240 with windows api wrappers removed.
  170 if you remove all subprojects (split on -/_ taking first field, then uniq).

  fast math and various hashes
  backtrace utils
  various build utils
  some allocators, zero copy facilities, mmap and structures   like lrus
  time and date handling
  character maps / internationalization
  concurrency libraries (futures, runtime, etc)
  cross platform path & directory helpers
  support for general unix platforms, for redox, for linux, for windows
  logging infrastructure
  some compression libraries
  markdown
  various testing helpers
  rope string representation
  shell lexer and utils
  terminal interaction models
  toml
  wasm & wasi

But once helix adds plugins it will be exactly the same because those tens of VSCode plugins provide functionality not present in helix, so will be similarly implemented externally

At least lua is a real language, i.e. a language used by more than just vim.

I use a plugin[0] for LSP in vim and it's pretty easy to setup there too. Installing and configuring the lsp software itself take more time as I'm constantly moving between OS.

Also, Emacs and Vim is very much about making the tool your own. I don't mind shaving the yak every now and then, because once an inconvenience is solved, it stay solved.

[0]: https://github.com/prabirshrestha/vim-lsp

ar_lan specifically mentioned Neovim distributions. Examples would be LazyVim and AstroNvim. These are packages you can install that provide Neovim in a pre-configured and opinionated way. They generally come with language servers, linting, and various other features out of the box, and have their own paradigms for configuration.

They can be easier to get started with than just installing Neovim from scratch. But they add their own complexities. First, you have to know that they exist, and pick one. Then you have to know how to configure them, they may have their own nuances about how things are done. Under the hood they're using all the same packages, so you'll need to learn how to configure those as well if you don't want the defaults.

I would say the distributions to make it extremely easy to get started with a functional IDE experience with LSP features. But they're not without their own learning curve.

I'm trying to be careful to distinguish that this particular part seems odd to me, specifically because of Julia's other posts in which it seems their skill/knowledge is not much of a question.

If someone is new to vim, I 100% agree that it's easier to get started with VSCode/Jetbrains/etc.

But if someone has been using vim for a long time as their default editor, especially Neovim, and when LSP support came to Neovim about 4 years ago [0], it comes across as someone who isn't a power user if they didn't end up installing it. Which is fine, but the community has also started to build reasonable "batteries-included" distributions of Neovim (LunarVim is a great example) if someone didn't want to figure it out themselves but still wanted to use it.

It's one thing if someone just doesn't love the experience Neovim brings to them. That's reasonable, because it's subjective. But it is odd to use a tool for so long and not further investigate what it offers to fit your needs. Before LSP, there were libraries (CoC for example). And if it was never satisfactory, why not look at alternative editors which had their own flavors of indexing/code navigation?

--

[0]: (https://github.com/neovim/neovim/commit/a5ac2f45ff84a688a094...)

When I worked with programming students we used VScode despite me, the professor, and most of the other grad students not liking it. It’s just so easy to download, has the “run” button, and, well, at least it isn’t Eclipse I guess.

Vim is better of course it’s just hopeless to get people to use it.

I think with Cursor choosing it as well, this will only continue to prevail. Professionally I've had to standardize on VSCode due to Cursor (there are a few plugins for Neovim but the experience is undoubtedly better in the first-class tool).

By the way - I actually generally think this is a good thing that companies standardize on something. I might not like the choice they standardize on, but the barrier to entry for new engineers is already high, so having an easy-to-use and familiar development setup that "just works" from the start is pretty reasonable for large companies.

4 years. https://github.com/neovim/neovim/commit/a5ac2f45ff84a688a094...

I think showing live preview for replacements is also a built-in Neovim feature now, but I can't remember if it's enabled by default or not.

That is not the same as helix multiple selections. I suggest trying our helix to really understand.

I really liked helix, but the problem is that pretty much everything I use is setup using Vim bindings (shell, browser, ideavim,...) so switching to helix concept of editing was different enough to require effort, but close enough that it screwed up all my other muscle memory.

If %s is Vim's answer to multiple cursors, then it's hopeless. I'm using both VSCodim and Vim, the former when doing dev, the latter for quick editing remotely through ssh. Tried Helix but it kind of annoyed me after years of using Vim.

> requires manual construction from a sequence of commands

Right, I saw some people share some snippets here before. But none of them act like Sublime does. I can't double-click a token and Ctrl + D to select next instances of it in my file.

There might be a better way but this bind works well for me in normal and select modes.

  C-n = ["search_selection", "extend_search_next"]

Does not work on Linux. Also, double-clicking to expand selection like in Sublime does not work.

https://github.com/helix-editor/helix/discussions/10208

mini.clue is another good option for this feature in neovim.

https://github.com/nvim-mini/mini.clue

Yeah, that's the mortal sin of vim - insisting on shitty unergonomic defaults, requiring every new user waste time recreating a better UI while suffering for years before even the appropriate knowledge is acquired

> if there's actually a choice to make.

I don't get it, there is always a choice to make, which is which action to continue with?

> Showing too many choices at once can be overwhelming

It can't be more overwhelming than having to remember all of those choices and using external docs/configs to look them up! Besides, it's not like there are no improvements possible and you have to show everything at once. For example, all your "all kinds of repetable actions" can be limited by the most frequently used 10 actions and an "others" submenu you could invoke separately if you were looking for something else. And your "another digit" is just a single line "0-9 continue the count", so what's the issue there?

It might have been a bit harder in the past, but with recent versions of neovim (>=0.11) it's less than 20 lines of configuration. I have quite a few keybindings to jump back and forth through errors and the default keybidings already include things like renaming, go to definition or listing references.

I'd be more than happy to help you configuring it to your needs.

    > I had to get my project to emit compile_commands.json,
    > get clangd, figure out which things about our build
    > process clangd was not understanding from 
    > compile_commands.json and add them in .clangd

    vim.lsp.config('ccls', {
        init_options = {
            compilationDatabaseDirectory = 'build',
        },
    })
    vim.lsp.enable('ccls')

Getting LSP to work on recent versions of Neovim is one plugin + one line of configuration. Here are the steps for enabling clangd:

1. Install nvim-lspconfig plugin

2. Add `vim.lsp.enable("clangd")` to init.lua

You can even enable LSPs on a per-project basis by taking advantage of the revamped exrc feature:

1. Add `vim.opt.exrc = true` to init.lua

2. Add `vim.lsp.enable("clangd")` to $projectdir/.nvim.lua

> every week or so there’s a segfault and the editor crashes.

It's not like Helix is as ubiquitous as Vim on a random remote server. If that's not the case surely the effort to install Helix is bigger than copying Vim config?

How is so? I have my dot files in GitHub. I just have to clone, run `PlugInstall` and it's all ready.

this was my plan, but then i got really into using LSPs and i'm not about to install every LSP on every server i ssh into.

Currently i just use sshfs to mount whatever directory i want to work on locally, nice to have all lsps available and also see my changes reflected on the server instantly.

Neovim with lazy.nvim has that by default (delay included).