I just heard of Helix and decided to take it for a spin. I'm not sure why I'd use it instead of Vim.
For all the Vim similarity, inverting the do-this-to-that seems like an arbitrary annoyance that I don't understand. Why go from "change this word" (cw) to "I want to change this word, so I'm going to select it first, then change it" (wc). I mean, it's not a big deal, especially if you're not already using Vim, but why THAT of all things? The difference is [explained] but the reasoning behind it is not.
Also the docs mention zero configuration but the first thing I had to do was find out why the LSP wasn't showing any information and then create a config file to fix it because the default behaviour doesn't show anything from the LSP, which makes it seem like it's not even there.
And there's no :help command.
Maybe it's a great editor, but I guess they're not targeting existing Vim users for conversion.
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.
> 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).
in kakoune, this is `<a-i>p<a-j>|reflow<ret>`. which is obviously not as simple as `gq`, but you can rebind this, add things like auto-reflow as you type, etc., rather trivially, and rebind them (and a lot of these types of tools come preloaded as bindable commands). it's some work to set up this type of thing (and it makes perfect sense to use e.g. vim to not need to do that), but i like the composable design, where i can write some configuration to hook a shell command to a bind, rather than fork and PR changes (e.g. a c++ reflow function), and the config files can be written and PRd into the default distribution as well, so the user experience would be equivalent.
apologies, i probably should've written `fmt` there (which does the same thing). `reflow` is a `fmt` clone i wrote, without the knowledge `fmt` existed --- that was a bit embarrassing for a friend to eventually point out, that my idea was already in coreutils :D i use `fmt` now because i figure it's far better tested (i think it's posix), but i still think of the action as a "reflow", and that's also the term helix uses.
'|' is the command to pipe a selection through a shell command and replace it with the output, so I guess it's just a regular command on their system. You could use any other reflow or reformatting program you had handy. Kakoune in particular is really serious about delegating everything possible to the system.
Honestly, it might have just been a placeholder name for an arbitrary formatter. I vaguely remember old-school unix had a command for that, but none of them seem to be named exactly "reflow".
It’s true. Once you master Vim, your journey to find the perfect editor will have come to an end. For the rest of your career, you can rest assured you will be using some form of vim.
But some people don’t actually want to find the perfect editor, they would rather stay on the journey forever, trying to master a new tool every few years. Sounds miserable, never knowing true mastery and enlightenment.
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.
From what I have heard, evil-mode does not give you an ability to touchtype, I mean totally blind typing without any pesky Escape Meta Alt Ctrl Shift chords.
I just heard of Helix and decided to take it for a spin. I'm not sure why I'd use it instead of Vim.
For all the Vim similarity, inverting the do-this-to-that seems like an arbitrary annoyance that I don't understand. Why go from "change this word" (cw) to "I want to change this word, so I'm going to select it first, then change it" (wc). I mean, it's not a big deal, especially if you're not already using Vim, but why THAT of all things? The difference is [explained] but the reasoning behind it is not.
Also the docs mention zero configuration but the first thing I had to do was find out why the LSP wasn't showing any information and then create a config file to fix it because the default behaviour doesn't show anything from the LSP, which makes it seem like it's not even there.
And there's no :help command.
Maybe it's a great editor, but I guess they're not targeting existing Vim users for conversion.
[explained]: https://docs.helix-editor.com/from-vim.html#migrating-from-v...
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).
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
in kakoune, this is `<a-i>p<a-j>|reflow<ret>`. which is obviously not as simple as `gq`, but you can rebind this, add things like auto-reflow as you type, etc., rather trivially, and rebind them (and a lot of these types of tools come preloaded as bindable commands). it's some work to set up this type of thing (and it makes perfect sense to use e.g. vim to not need to do that), but i like the composable design, where i can write some configuration to hook a shell command to a bind, rather than fork and PR changes (e.g. a c++ reflow function), and the config files can be written and PRd into the default distribution as well, so the user experience would be equivalent.
> i can write some configuration to hook a shell command to a bind
is `reflow` a binary that comes with kakoune or something?
apologies, i probably should've written `fmt` there (which does the same thing). `reflow` is a `fmt` clone i wrote, without the knowledge `fmt` existed --- that was a bit embarrassing for a friend to eventually point out, that my idea was already in coreutils :D i use `fmt` now because i figure it's far better tested (i think it's posix), but i still think of the action as a "reflow", and that's also the term helix uses.
'|' is the command to pipe a selection through a shell command and replace it with the output, so I guess it's just a regular command on their system. You could use any other reflow or reformatting program you had handy. Kakoune in particular is really serious about delegating everything possible to the system.
I’m curious about the particular program though! On my Mac it doesn’t exist and I didn’t find it in a quick search
Honestly, it might have just been a placeholder name for an arbitrary formatter. I vaguely remember old-school unix had a command for that, but none of them seem to be named exactly "reflow".
It’s true. Once you master Vim, your journey to find the perfect editor will have come to an end. For the rest of your career, you can rest assured you will be using some form of vim.
But some people don’t actually want to find the perfect editor, they would rather stay on the journey forever, trying to master a new tool every few years. Sounds miserable, never knowing true mastery and enlightenment.
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.
What are your differing use cases for each editor?
My work setup is simply too complex and uses too many plugins to work in Helix as of now.
For all personal work and just quick text editing I use Helix. If I could use Helix for everything I would
Where does evil-mode land?
From what I have heard, evil-mode does not give you an ability to touchtype, I mean totally blind typing without any pesky Escape Meta Alt Ctrl Shift chords.