Hacker News Reader

Comment by phplovesong | Hacker News Reader

Skimmed only. Most titles was like "i use X for that" then scrolled down for the next one.

And thats the thing. Neovim (vim) is about the unix way, use existing tools and use them from vim.

Last time i checked this was not an option in helix, and some very trivil things was impossible, like populating the quickfix (is it a thing n helix?) from a makefile command.

Bottom line is helix is basically a stipped down version on vscode, and wont really succeed without a plugin system (and when/if it lands, its basically just a vscode alternative)

View on HN

I use kakoune, and don't understand why helix seems to be taking off while kakoune (which predated and inspired helix) remains niche.

Kakoune fully embraces the unix philosophy, even going so far as relying on OS (or terminal-multiplexer, e.g. kitty or tmux) for window management (via client/sever, so each kakoune instance can still share state like open buffers).

A comparison going into the differences (and embracing of the unix philosophy by kakoune) by someone who uses both kakoune and helix: https://phaazon.net/blog/more-hindsight-vim-helix-kakoune

Sensible defaults and easy setup are a big deal. No one wants to fiddle with setting up their lsp and tree-sitter. There's probably more to their differences in popularity than just this, though.

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.

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.

The biggest benefit is multiple cursors. The helix and kakoune multiple cursor implementation are probably the best in any editor. It just goes hand in hand with selection first.

The problem with that editing model for me is that it makes text objects much more cumbersome.

In Vim you can for example do "dap" to delete around a paragraph, but you cannot easily invert it ("pad") because 'p' is too common and is already bound.

You can also easily do the "select first" in Vim by first pressing 'v' to start a visual selection, so I just don't see the point.

This bugged me for reasons I can’t quite explain. I think it’s that I can write and edit the command before making the modification and the ease of going back and reusing a historic search and replace relatively easily.

I spent about a month trying to get used to Kakoune. It never clicked with me and I went back to vim.

My biggest beef with Kakoune’s editing philosophy is that it seems to emphasize “editing in the large” as its preferred mode of interaction. This is totally backwards to me. Editing in the large (making multiple identical edits throughout a buffer) is a rarity. Most edits in day to day use are single edits. So the fact that Kakoune likes to leave a bunch of extra cursors in your wake (like a trail of breadcrumbs) as you jump around a file to make single edits is extremely infuriating to me, like it’s trying too hard to be helpful.

The irony of Kakoune using a clippy-style contextual help window is not lost on me!

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.

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

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.

Helix inverts the verb-selection paradigm in the same way as Kakoune.

Appreciate the clarification, I guess I didn't get far enough into `:tutor` to see that.

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

>Last time i checked this was not an option in helix, and some very trivil things was impossible, like populating the quickfix (is it a thing n helix?) from a makefile command.

Not sure what "trivial" is trying to convey here, but in any case personally I would put quickfix list as a rather advanced feature. Like in the excellent book Practical Vim[1] its covered in chapter 17 on 21 chapters.

[1] https://learning.oreilly.com/library/view/practical-vim-2nd/...

`ed` is really much more in the spirit of unix. `vi` culture popped up since then, and the idea of driving other tools from an editor is more of an emacs/lisp lineage.

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

Reply on news.ycombinator.com