Comment by brixie | Hacker News Reader

Comment by brixie | Hacker News Reader

On the discussion of values, I'd also like to submit "(expected) longevity" for consideration, which I think is distinct from "stability".

I made the switch from Vim to Neovim as soon as I felt confident that (1) the project was going to be around for a while, and (2) it was on track to "overtake" Vim (you may choose to disagree with me on this, I found built-in LSP to be a compelling selling point, but the specifics aren't really related to the point I'm trying to make). That it was almost completely a drop-in replacement, down to the init file, certainly didn't hurt.

Under the author's framework, Neovim apparently prefers "progressiveness" while Vim prefers "stability", and those two sound dimetrically at odds based on their descriptions; but both have large, active communities that aren't going anywhere. I'm not sure I can say the same about Kakoune, for example, which is a certainly a promising project but hasn't yet convinced me to jump the fence.

[edit for Emacs thoughts]: Now that I think about it, "text centrism" in my mind is also closely related to longevity. I don't care as much about the properties of plain text as I do about the fact that I'll be able to open/view/edit them _even if the application ecosystem dies_. I find Emacs attractive here with org-mode and, to a lesser extent, org-roam (the comparison here would be between e.g. SaaS productivity offerings like Notion).

> I'm not sure I can say the same about Kakoune, for example, which is a certainly a promising project but hasn't yet convinced me to jump the fence.

I've made that jump a couple of months ago, and so far I love it. There isn't as large of an ecosystem, but Kakoune just feels better integrated with the environment. Is your hesitancy based on some particular feature, or the ecosystem, or something else? Or is there some default that you dislike?

I feel like it doesn't need to have as many maintainers in order to be successful, because its philosophy is much more spartan. The maintainers pretty aggressively keep the project's scope in check.

I haven't tried Kakoune, so I'm not really qualified to speak about its merits or demerits. From a place of limited knowledge, I see nothing wrong with it, and want to reiterate that it seems really interesting and worth keeping an eye on.

To add some nuance to my earlier comment: I don't really worry about the existence of Kakoune (or $OPEN_SOURCE_SOFTWARE_PROJECT) in a trivial sense; we'll always be able to find a copy somewhere and compile it from source, modify it, etc. That being said, I think one of the advantages of a large/durable ecosystem is that it lets me worry less about problems I don't yet have. I use (neo)vim daily, but there are certainly still lots of ways I can improve my workflow. Inevitably I'll run into something that goes wrong or doesn't work like I want it to, and a larger and more active community makes it more likely that someone else has already figured out how to fix it.

The (relatively small) differences in keybindings are also worth a mention, but I think the vims have a bit of an unfair advantage here; IMO learning vim keybindings is almost unquestionably a good investment because you'll find them everywhere.

> Kakoune just feels better integrated with the environment

Out of curiosity, is this an argument for enjoyment or productivity? :) (Either is a fine answer! I frankly can't measure the latter so my personal usage of vim is probably motivated by the former.)

> I think one of the advantages of a large/durable ecosystem is that it lets me worry less about problems I don't yet have.

That's true. If you're finding numerous workflow problems with neovim, it'll probably be true of Kakoune, as well.

> > Kakoune just feels better integrated with the environment > > Out of curiosity, is this an argument for enjoyment or productivity?

Both, though it's a more persuasive argument for productivity. Because it's easier to integrate with the environment, those workflow problems you mention can be solved by delegating to the environment, in some cases. For example, kakoune delegates to the environment for window management -- so things like resizing windows and switching between them is handled through tmux for me. Obviously, though, that's could be a poor substitution for some dedicated solutions in the editor. But overall, I prefer it, as it allows me to get familiar with unix utilities, which are useful in a wider range of applications. It also means there isn't an arcane scripting language associated with using the editor. I have a thing against vimscript.

> differences in keybindings are also worth a mention

I suppose. Having used vim for years, I was able to pick up the keybindings relatively quickly (< 1 day); they're almost identical. The main difference, that the selection comes before the action, also makes it easier to pick up.

But, yeah, that muscle memory is a loss. I find myself trying to do multiple selections and use kakoune keybindings in bash vi-mode, often.

Does neovim have a gvim equivalent nowadays?

The redraw speed for gvim on native ubuntu is awful, you can literally distinguish when top and bottom of the window is drawn, it doesn’t feel good. Sublime Text redraws almost instantly the entire window when you page through code.

Reply on news.ycombinator.com