[spapas82]

Helix is great and includes a lot of stuff out of the box (file pickers, syntax highlighting, linting etc) without any configuration or installing plugins (contrary to vim or neovim).

I would definitely use it but the main disadvantage is that some keybindings work differently than vim. I understand that the keybindings may be better that the vim ones but after years of using vim I expect "x" in normal mode to delete the character under the cursor or "d" to wait for the motion before deleting anything. When this does not happen I get confused and angry. I think this would be a problem with most people that are using vim; it's very difficult to change your habits especially since you can't ever escape from vim because of its ubiquity.

Thankfully, some good people have released evil-helix, a soft fork of Helix which introduces Vim keybindings https://github.com/usagi-flow/evil-helix ; I tried it and it works great so I'll totally recommend it to people that have my problems.

As a final notice, helix (and evil-helix) works great in Windows (cmd). No need to install rust or anything. Get the .exe and you're gtg.

[mmcromp]

For me, the issue isn't that I'm unwilling to learn new things. It's that I cannot use these keybindings anywhere else. Almost all online editors and workstations have some sort of vim keybindings. When I ssh into a Linux machine I can trust it has vim editor. It's like qwerty keyboard, I'm sure that there's better layouts but I just cannot discard the flexibility of being able to jump on most machines and be 99% productive almost instantly.

[eviks]

> I just cannot discard the flexibility of being able to jump on most machines and be 99% productive almost instantly.

You can easily discard it if you can become 200% productive with better defaults on your machine. Like, do you also not use any plugins just because they aren't available on another machine?

Also the keyboard comparison doesn't work since it's not as hard to copy your editor to another machine

[coffeeindex]

> do you also not use any plugins just because they aren't available on another machine?

The vast majority of plugins don't fundamentally change how you interact with text.

[eviks]

So? Narrow it down to the most useful minority that do, the question still remains

[coffeeindex]

If you narrow it down to that minority that fundamentally changes how you interact with text, then I think the answer is a pretty easy "Yes".

[dpatterbee]

Honestly, I don't think this is a big deal. I use helix as my primary editor, but when I'm on another machine and it only has vi or whatever I just use that and I can mentally switch to using the vim keybinds with little issue. Like sometimes I'll mistakenly `m-i-w-c` instead of `c-i-w` or `d` instead of `x`, but then I just hit `u` and continue.

[4b11b4]

I know right

[zeendo]

To anti-pile-on to the other replies - this is exactly why I haven't given it much of a spin.

I'm glad to find out about evil-helix.

[Barrin92]

i didn't find it to be a big issue because helix doesn't have different key bindings as much as it simply has a reverse grammar. If you think of vim as a language to manipulate text objects (which is what it is basically) everything is verb-noun, in helix it's noun-verb. There's a few idiosyncrasies but approaching it that way I got around pretty much immediately.

[_cwpi]

I'm totally fine with (re)learning new tools, but having given Helix a solid try found the noun-verb model worse; the visual feedback is fun but distracting, particularly when you're moving around reading code. For it you give up things like repeating edits easily (bound as '.' in Vim). There's also a statefulness to Helix's model that isn't present in Vim; whereas in the latter I only have to care about where I _am_ in the file as I'm making my edit, in Helix I have to care about where I've _been_ because that dictates what I've currently got selected. See my other comment for details.

I want an editor with OOTB configuration and a modal editing paradigm (probably Vim's) that isn't constructed around visually synchronizing every edit action. Doing the latter means relinquishing what's good about an editing language, which is that you needn't actively think about edits so much. It's not about speed, but freeing up mental resources to think about the more interesting programming tasks at hand. Editors that demand more attention are doing a worse job.

[zem]

surprised helix doesn't support the . key - is that incompatible with its interaction model somehow?

[_cwpi]

Yes, its model is that you make a selection and then act on it. After the action happens there's nothing selected. The editor can't infer your intent in making the selection, so there's no reasonable notion of repeating the last edit. You can separately repeat the last motion or last action, but not the whole edit---which of course isn't as useful.

Helix would _ideally_ like you to tell it ahead-of-time everywhere you're going to make an edit by selecting all the edit points with multiple cursors, without a great option to fire edits on the fly. Ironically I found this worse for visual feedback when making larger edits---where it's most needed---because there are usually edits happening off screen, instead of only at the point of the cursor (where the latter can be easily repeated).

It ends up feeling less interactive and more like I'm using a batch editor due to this, which (I think?) was not its intention.

[latexr]

In that situation, what I do is essentially save a macro (recording the selection and the edit) with `Q` and then `q` becomes my equivalent to `.`

[_cwpi]

Good note; there's almost always a (somewhat less convenient) workaround. I find the visual feedback that induces these compromises actively annoying, so don't want to give up anything for it. Different strokes, of course!

[4b11b4]

Hmm

[smohare]

The existence of a repeat or “magic” key is one of the more interesting developments alternative keyboard layouts designs. The use case is slightly different of course.

But as an extremely heavy user of vim repeat and macros for the last two decades, it strikes me as a wee bit audacious to so completely dismiss its utility.

[latexr]

As someone who used vim (and then neovim) for some two decades, I didn’t find it hard to adapt to helix, and now vastly prefer it.

I did edit several modal behaviours but always stick to helix logic.

Things like the multiple selections and LSP support out of the box make it super worthy, aided by its fantastic help that when you press a multi-step character it shows a little hint of possible next options, including your own custom actions.

I do on occasion need to use bare vim setups, and while some commands have been remapped in my head, I still remember enough for quick edits.

[positron26]

Helix is adding a Scheme for programmable configuration.

With programmability, you can have a lot more state and contextual behavior. We get this kind of fine-grained stuff in Emacs with repeat maps, transient maps, heuristic DWIM behavior, state tracking per-buffer etc.

As LLMs lower the cost of having that 8th or 9th language, you can expect programmable tools to float up in the market.

[mi_lk]

Omg. Vim keybindings is the single blocker for me to try helix.

It means that it's possible to add vim support for Helix but they don't want to?

[justusthane]

Sure, why wouldn’t it be? Plenty of programs have Vim keybindings. The challenge is matching the behavior perfectly 1-1.

[phatskat]

This is where vim keybinds fall short every time. I do appreciate the effort, and have zero expectations about a one to one match, but the moment I do something out of habit and an editor doesn’t do what I expect, in “vim mode”, it breaks the illusion.

[qn9n]

Honestly most implementations are just the basic navigation keys and a couple of edit commands. The basic navigation in Helix is the same as Vim so the ubiquitous feeling continues.

[bestouff]

Same same.