i remember him mentioning that he had at least heard of it in a post from years ago.
vis is cool but its structural regular expressions are much less easier to use since kakoune's give you feedback in real time. it is nice that vis actually has a lua API though.
Is it worth learning Dvorak? Sure it makes sense on paper, I see the rationale behind it, but I've already been typing on QWERTY all my life and I'm pretty fast at it. Kakoune is the same thing for me - the things
changed from Vim make sense, but I don't see it as good enough to offset the facts that:
1. Vim is muscle memory for a lot of us. Something that is so similar but not quite the same just fucks with my brain. I have an easier time using stock Emacs bindings than Kakoune, as my brain is not in Vim mode while using it.
2. VS Code, Fat Visual Studio, IntelliJ, Emacs, most IDEs/text editors, fuck even Compiler Explorer have Vim plugins that range in quality from acceptable to fantastic. You can get a fix for your vim needs even in a disgusting corporate Windows crackhouse environment.
3. If you're a purist, Vim itself has a great ecosystem, and can be reasonably used for a lot of tasks.
The second point is the biggest reason why I haven't switch to Kakoune or Helix yet. I've used vim for just over a year now and I'm still annoyed at how unintuitive some things are, I still can't remember half of the shortcuts. I tried out Helix and it's great! I especially love the multiple cursors.
But I never use vim by itself, I use it in other apps. And there's a perfectly good Helix plugin for VSCode, but I also use vim mode in Obsidian (since I'm constantly switching back and forth between Obsidian and VSCode) and there is currently no plugin for anything else. I need my code editor and my note editor to have the same controls, otherwise my brain gets confused.
Once a Helix or Kakoune plugin is created for Obsidian, I am switching straight away.
Vi-style binds are moderately unintuitive, but they are the lingua franca of keybind languages, and knowing them has value in and of itself. I'm glad I learned vi-style binds just before Kakoune and Helix gained popularity, as I use them in dozens of contexts other than my text editor.
Oh... For my part, other binds are weird and less ergonomic from far. I'm vey used to vi-style: I mostly work in text mode (no GUI, no mouse) and I like to talk to my editor what I want...
Take a look at https://helix-editor.com/. It is basically a continuation of the ideas behind Kakoune but with a primary focus on modern day programming with a language-server. I use it for most of my programming today, because the language server support out of the box is just so much better than anything I managed do with Neovim.
yeah, the lack of a plugin ecosystem and consequently, copilot support, is the hardest pill to swallow with Helix right now. that said, its an amazing editor. excluding the plugin stuff, its batteries-included and is so refreshing to not have to mess with configuration files just to get it to a useable state.
Maybe it's just me, but a TUI-only editor is a non-starter for me, for a number of reasons, first being that my terminals are set up for maximum readability for shorter sessions, not eye comfort over hours.
exploring large codebases is hard in tui editors for me too. there are certainly times when i switch to vscode when i’m working in a monorepo for the graphical file tree.
The theories behind newer layouts are solid I think, but I’ve avoided adopting them simply because if I don’t regularly use QWERTY, my capacity for using machines other than my own suddenly takes a steep nosedive.
My preferred layout is HHKB/Tsangan, a minor variant on QWERTY that replaces Caps Lock with Control, moves Esc to the number row, collapses F-keys into a number row layer, and moves Backspace down where backslash/pipe are and even with that standard keyboards can be frustrating (you don’t realize how hard standard Esc and Backspace positions are to reach until you’ve tried this layout). I can’t imagine what it’d be like if I were using DVORAK or something.
I used Dvorak for awhile. It's okay, at least better than QWERTY. But it's super old, and keyboard layouts post-Colemak take advantage of rolling bigrams and trigrams, unlike Dvorak. I use Hands Down now.
https://sites.google.com/alanreiser.com/handsdown
Its a funny thing. I swapped to Colemak, was definitely worth it. I am pretty sure there are better layouts, but also I'm so wary of falling into a sort of productivity-tool/gear-acquisition-syndrome where I can never settle on one that is "perfect".
Swapping wasn't hard, but it sure wasn't easy. Did you find going from B -> C (-> D?) easier than A -> B?
I have at various times in my life tried to use vim or emacs. Each time I get comfortable enough in them to appreciate them but I run into the same problem every single time: it is annoying to switch back out of them.
I had an acquaintance that told how he had spent years investing in Dvorak. He came back to QWERTY because he got a job where he had to jump onto others computers on occasion. The friction he felt fighting against his muscle memory was more annoying than any benefit he got from the supposed better Dvorak layout.
I now use VSCode for 90% of my stuff and I use vim whenever I ssh into boxes or if I really need a quick edit from the CLI. But I keep vim totally stock, not a single thing in my dot file. There are aspects of my previous highly-customized and personalized vim setup that I miss - but I am free from the frustration of them not being there.
As I get older, freedom from frustration has become more important than the marginal improvements of customization for efficiency.
Funny, you use VSCode for the same reason I use Emacs -- so I can keep vim totally stock, so I'll retain the muscle memory / not be shocked on other systems, and so that it remains completely reliable and fast on my own.
I'm incredibly skeptical, however, that VSCode has as-good of a vim emulation layer as evil-mode. Evil-mode is just fantastic. Customized Emacs w/ evil-mode gives me everything I'd get from a fancy IDE, and keeps my vim muscle memory intact for those times when I am using regular vim.
This has been my pattern for a decade and it's glorious. GLORIOUS, I tell you! Few things give me joy in computing like the balance in the Force that I've managed to strike between Emacs and vim
For sure, Emacs with evil-mode is the best of both worlds: deep customization and sane configuration language of Emacs, with the arguably superior modal interface of Vim.
Using mnemonic key bindings is much friendlier than dozens of random key combinations. There's a popular key-chord package[1] that minimizes this discomfort, but without editing modes, users need to be concerned with the chords clashing with their actual text, which is absurd. Modes address this issue gracefully.
I still use some basic combinations like M-x, but I would be completely lost in Emacs if it weren't for evil-mode. <3
The thing with modal UIs is that you want to use them everywhere. So I also enable vi-mode in my shells, and in any application that uses readline.
This is pretty close to how steno [https://www.openstenoproject.org/] works in practice and worth learning IMO if you are going to go this far. In fact I have a few emacs-specific chords, but not as many as you might think. The whole experience is a bit like if emacs is now your keyboard, so it happens to go great with emacs.
There's two VSCode vim plugins, one a native one and the other actually uses neovim. They're both pretty good. The main downside is that VSCode plugin can take some time to startup.
I use the native one as it's a little less "pure" about VIM and integrates better with VSCode things. Overall it's less evil than evil. ;)
I never understood the logic of not using something because it's difficult to switch away from it.
If I need to program, I just copy my Emacs configuration to that machine. I have never encountered a situation where I'm forced to use stock Emacs, or someone else's Emacs configuration. If I need to make a quick edit from the CLI, using plain Vim is fine, but I feel more "at home" with my own tweaks. None of these things are hurdles that would make me settle for an editor that someone else has preconfigured for me.
At the end of the day, this will depend on how important you find customizing your working environment to your liking. If you're fine with someone else making that decision for you, you'd probably find the stock configuration, or someone else's configuration, acceptable. If OTOH you have strong opinions about the way you want to use your editor, then the time and effort invested in configuring it and managing that configuration is not an issue.
This goes beyond just text editors, and applies to computing in general. Some people are fine with using stock software as it comes from the manufacturer. Most software, in fact, is not deeply configurable. Apple devices and software are wildly popular despite lacking configuration. But the reason we choose operating systems like Linux, and text editors like Vim and Emacs is precisely because they give us the freedom to use our computers in the way we want to use them, not as someone else thinks we ought to.
If you're worried about having to relearn Vim commands, it's not a big deal. You're not remembering the key positions but the mnemonics, so "dta" means "delete to a" not some key positions. You'll be fine.
> If you're worried about having to relearn Vim commands, it's not a big deal. You're not remembering the key positions but the mnemonics, so "dta" means "delete to a" not some key positions. You'll be fine.
Oh man, this was so difficult for me with a split ortho keyboard. I realized that most of my bindings now i don't actually "know". It's 100% muscle memory.
I had to keep a keyboard handy to "do the thing i want on the unplugged keyboard" to see what the bind was. Kinda mind blowing to me hah.
sure, but that's the same argument against any form of incompatible change.
it was used against the fish shell for example. yet eventually it started getting acceptance. the same may happen with kakoune. i tried using it myself. i wasn't so much bothered by the changes. i had different issues. i got burned by kakoune overwriting a file without warning me. vim would not have done that. and i couldn't get over the fact that kak means shit in some languages. it will take some more effort to overcome that and give it another try.
I come out of the woodworks every now and again whenever I see Dvorak mentioned in any context. I really despise its popularity as an alternative keyboard layout because I feel it wasted a good year of my life.
1) Few people will have benefit of learning Dvorak. What benefits they see comes from learning how to properly touch type by forcefully breaking bad habits with their original (usually QWERTY) keyboard layout.
2) Switch to Colemak or any more modern layout that takes advantage of bigrams/trigrams better. Colemak is genuinely superior to QWERTY beyond just learning to touch type.
I used to type 170~ WPM on QWERTY. Sustained. By all means an accomplished typist. I learned Dvorak well enough to get back up to 120~ WPM but saw no real benefits of using it: I already knew how to touch type. But QWERTY was causing my hands to cramp up over time and so I was on the search for improving that. I gave Colemak a try and it was a great relief. I only type 150~ WPM on Colemak after some years of using it but the lack of pain from typing for long periods of time is worth the small hit to my typing speed.
Almost every single person I see who touts benefits of learning Dvorak was typing <60WPM in QWERTY and did not know how to properly touch type. The benefits they see weren't from using Dvorak: it was from finally learning how to touch type properly.
Apologies as I know Dvorak wasn't really the focus of your post here. But in an attempt to perhaps make it still relevant: change every now and then is good. It can break you out of bad habits you didn't know you had learned and sometimes open you up to new ways of accomplishing something. As other replies have mentioned - I'm a big fan of Helix and gave up Neovim for it.
Eh, I'd say it kinda depends, Colemak focuses more on rolls while Dvorak focuses more on alternating between hands. Though I think that Workman is a superior alternative to Colemak when it comes to ergonomic rolls.
Xah Lee wrote an analysis on why he believes Dvorak is better than Colemak: <http://xahlee.info/kbd/dvorak_vs_colemak.html> and he brings up the frequency of the "th" digram, which on Colemak is a bit of an issue due to the finger travel.
I can touch type on QWERTY, and last I measured I hovered at around 100 WPM on my best efforts. But TBH typing speed is really not something I'm concerned about. When I'm programming, accuracy is more important than speed, and I spend much more time thinking than actually typing. And when I'm writing prose, I also make pauses to rethink what I'm writing, and go back and forth, refining the text to match my thoughts. So even if I typed much faster, my overall speed of communication or programming wouldn't improve.
I also haven't had any discomfort after decades of typing on QWERTY keyboards. I find it hard to believe that a different layout would reduce discomfort more than using an ergonomic keyboard, with proper wrist support and posture.
I understand that Dvorak hasn’t been great for you, but I don’t think it’s fair to attribute all of its success and merits to touch typing. The distribution of keys is obviously more optimal than than of QWERTY, and even if your analysis holds true for some Dvorak typists, I doubt it does for a majority (or even a significant portion) of them.
Speaking from my own personal experience, I learned to touch type (properly) on QWERTY first, but after a while I switched to Colemak. After yet another while, I switched to Dvorak, and have been using it for several years now. For me, Dvorak has been slightly more comfortable than Colemak (which, in turn, was much more comfortable than QWERTY); though I have to admit I’ve never experienced significant pain or cramps just from typing. In any case, I find both layouts to be a great improvement over QWERTY, and certainly not only because of touch typing.
The primary difference is rolling vs alternating (as someone else mentioned) and slight left vs right hand biases (I don't think anyone brought this up yet) and there is some definitely enough room for preference of one over the other there. I prefer rolling over alternating and I'm left-hand dominant. For finger alternation I'd recommend any of the CarpalX layouts (Qgmlwb specifically). If I knew about CarpalX before learning Colemak I probably would have learned it instead but I also don't want to relearn typing for a 4th time.
There's always a handful of exceptions to every rule but by and large from my experiences in the altkey layout communities the people who touted Dvorak the loudest largely didn't know how to type properly before learning Dvorak and it was their first alternative layout learned. So it's colored my view a bit.
I have regularly typed for >8 hours/day - nearly every day - since age 8. The hand pains didn't really start until I was in my 20's.
> What benefits they see comes from learning how to properly touch type by forcefully breaking bad habits with their original (usually QWERTY) keyboard layout.
With that I fully agree, but then again - in my mind that exactly is the value proposition of any non-QWERTY-layout.
I also agree that ergonomics is more important than peek throughput.
But you neglect the cost. The cost of ruining shortcuts in many applications and/or complex OS settings just to be able to type. There are workarounds and solutions for most but I haven't been convinced it is a net gain.
So in my opinion, stay and invest in QWERTY instead. Regarding ergonomics use a split ortholinear keyboard. I am in doubt any layout will be as liberating as that and orders of magnitude less investment in time.
Everytime I use or think of a staggered keyboard I'm amazed at the design. Put your right hand over the right hand of the keyboard as if to type, the columns kind of naturally go with your fingers - not bad at all really. Then do the same with your left hand and it is just a clusterfuck.
Though I do have to acknowledge two things, you can of course use and benefit from an alternative layout on an ortholinear keyboard as well. And the cost of only feeling at home on a bespoke keyboard (not that it is different enough for you to not be able to use a normal keyboard) isn't negligible depending on your situation either.
One even bigger problem with Dvorak isn't the speed, which is actually very hard (next to improssible) to objectively measure; it's that you lose the ability to write on somebody else's computer, or phone, depending on where you're using Dvorak.
Especially when programming. A lot of key shortcuts are specifically designed for QWERTY. And if you believe that the keyboard should be re-arranged to better fit the language then shouldn't a programming layout have more easily reachable symbol characters? (and varying depending on the language).
Every other keyboard you may need to use; for family, work, friends, is QWERTY. That is enough reason for me to stick with the norm. I already type 120wpm, which is only useful for a speed typing test. I never code, or even write documentation, at 120wpm.
Regarding (1), I used Vim for 19 years, and I had strong muscle memory. However, I found it took only about a week to get comfortable with Kakoune. Its multiple-selection-oriented editing just mapped really well onto how I was already using Vim, which is to say, making extensive use of visual mode and highlightsearch. I have met Vim purists who tell me this is missing the point of Vim. If so, all the more reason to make the switch. But if verb-motion works better for you than selection-verb, by all means continue using Vim; it's a great editor.
It's worth getting a physical keyboard that's actually ergonomic, like a Keyboardio, ergodox, dactyl, or whatever. Just pick the one you are most excited about using.
It's significantly less valuable, but still worth learning an alternative keyboard layout, though Dvorak specifically isn't nearly as good as modern alternative like Colemak or Workman.
Vim is incredible for every reason except its keybinds. Technically, you can remap them, but that quickly devolves into dependency hell... learning to type using the Workman layout is why I'm an Emacs user today. One of these days I'll get around to making a truly configurable modular editor...that will most likely be an Emacs config.
I switched from a standard split ergo keyboard to a split orthographic with curved rows (Glove80 specifically). I'm still questioning my move. I was pretty damn fast with the standard split, and I'm still struggling with special characters on the Glove80. It feels like it's coming though, and at least it's fun. And perhaps it will reduce wrist and finger strain as I get older.
I love that we have so many choices for editors. VSCode, Vim, NeoVim (+ vim distros like astro etc), emacs (+ emacs distros), Kakoune, Helix etc.
Its awesome to have so many choices so everyone can pick the system that best fits them. It also encourages better tooling that can fit on top of any of these like the Language Server Protocol, TreeSitter etc which benefit everyone.
Thanks to everyone for working on all these projects and tooling, its truly incredible.
Kakoune has the nicest regex interaction I've ever used in a text editor. It's feature complete and accessible from a single keystroke out of the box. You can write key macros that input regex to do surprisingly complex motions without any scripting language.
For those that have used Vim/Neovim, Kakoune, Helix and other terminal editors, which one is your favorite? I use VSCode and have been looking to switch, I use Neovim inside VSCode (without the emulation of something like VSCodeVim) [0] which is decent but that's mainly because I don't want to set up all the plugins for Neovim again. Helix seems interesting because most things are built like with VSCode, it just works™, but I have to learn a new keyboard control scheme.
IMO learning the helix keybindings is definitely worth it. Install it, check with `hx --health` what LSPs you need and install these and that's it. And you still have so much configuration you could do, but don't really need.
There is still no plugin support for Helix though right? That's what keeps bringing me back to VSCode, there is always something missing in each editor I look at. Same for VSCode though to be fair, it's sometimes slow on large files and especially when doing type checking, but it's a trade-off I'm making for its DX, I suppose.
I like that Helix's approach is different, and I think the lack of plugins is essential for it to remain on its chosen path. If Helix got plugins, then soon enough everybody would be scratching all their itches using plugins, there would be no users for the core functionality, and it would be the same kind of ecosystem we already have for emacs and Neovim.
What would be ideal for me, but probably not possible in reality, is an editor that cannibalizes popular plugins. So, if a feature is sorely lacking, the plugins appear, but eventually the core functionality grows to replace the plugins. A new user installs the editor and gets a rich set of features that are battle-tested and built to work together. What seems to happen in practice with emacs and Neovim is that the core never gets any bigger, so a new user gets zero benefit from those decades of work, experimentation, and discovery, until they invest the time to integrate dozens of disparate packages into their own setup which they will have to maintain themselves over time.
But that seems to happen in practice with emacs and vim, why would the newly designed editors follow the same rotten path, after all they've managed to break some significant conventions of those other editors?
The other "in practice" side is that without plugins the editor will never get as good as a properly (though painfully, though less painfully with some preconfigured distribution) configured alternative one with plugins
I'd probably use Helix if it had 1:1 Kakoune keybindings. Or even Vim bindings.
Vim bindings are not the most consistent, but they are ubiquitous. Every program that offers Vim mode has very similar keymap. If modal text editor deviates from them, it better be for good reason.
Kakoune bindings are very different from Vim, but they are provably and objectively [1] better, so that's fine. They are also more consistent and there is a clear idea behind the whole design. It's written down in documentation. You might prefer Vim or Emacs, but at least you can see that changes from well known Vim scheme are not made at whim.
Helix keymap feels like it was improvised without any thought behind it. „Let's take Kakoune binds and add back visual mode cuz I feel like it.” Currently, they are designed by committee in this GitHub issue[2]. I don't see any design notes and explanations why should I spend time learning Helix keymap.
To be fair, before I used helix, I only used neovims basic keybindings (hjkl, dd, ...) and nothing advanced, so I didn't really need to 'relearn' much, but I completeley understand when someone used a set of keybindings for some time it's really hard to switch.
I think the biggest benefit of going away from something like VSCode or IDEA is frictionless creation and integration of new tools. VSCode and IDEA usually require you to write plugins to achieve a deep level of customization for your needs, which causes a lot of friction. In an environment like Vim and Emacs, you can make quick scripts that create new features for your project that you wouldn't have created otherwise.
I'm currently using VSCode, but I don't code a lot these days. If you are looking to explore a new paradigm like that, I would go with Emacs as a practical option (with vi bindings) and Acme as a way to open your mind (but not very practical).
True, that is a benefit, but realistically though, I probably won't be writing any scripts or plugins myself for the editor I use, same as with VSCode, I just get them from others or on the Extension Marketplace.
I've used all except Kakoune. For me, Neovim is the one that stuck. Helix is cool, but having no plugins is a deal breaker (for now!) The onboarding experience is much nicer for sure, and Helix's LSP is way easier to set up than Neovim's.
That being said, Neovim, once you get it set up, is great. The biggest hurdle for me was the config, but if you just start from scratch and make a light config (mines about 200-300 lines, with LSP, hints, etc) you can get through it. And you never have to touch it again, since most likely you configured it in a way you like. Well unless you wanna add the occasional plugin. There are also distros of Neovim that contain a fully baked IDE-lite experience, but honestly those have extremely complicated config, and often IME don't feel nice and light.
It's definitely not for everyone. There is that time investment to get started, but it's definitely been worth it for me.
> And you never have to touch it again, since most likely you configured it in a way you like.
That was the issue for me, there actually is quite a bit of churn in the Neovim plugins ecosystem compared to VSCode (Packer vs Lazy for plugin management is just the latest iteration). I used to have Neovim plugins all built out but the churn was too much for me.
Oh yeah for sure. I haven't had that happen to me, but when I dropped AstroNvim, I had a chance to start from fresh (on lazy).
Small customized config also means smaller and more precise changes. I haven't touched mine in quite a long time, only usually to add that cool trick or plugin that pops up every so often.
I've used vim-plug for over a decade and it's been working fine. Yes there has been a lot of churn within some plugins, but overall it hasn't been that bad in my opinion.
And with lazy tracking plugin versions in a lock file, it's easy enough to pin plugins to a known good version whenever something breaks.
(I finally rewrote my entire config, and lazy is vastly better than vim-plug. I should've done so sooner.)
> (I finally rewrote my entire config, and lazy is vastly better than vim-plug. I should've done so sooner.)
What's better about it? I ask because I've been using `Plug` since I switched from pathogen (what feels like) an eternity ago and I don't really know any reason to switch because it just sort of works...? Every few years or whatever I'll overhaul the config (not a choice but it just sort of happens) and I'm curious whether switching plugin management plugin has a point.
- You can specify plugins dependencies, instead of having everything in a big list.
- You can separate each plugin setup/configuration into separate files.
- It tracks plugin versions in a lock file that you can commit into git. Makes it easy to identify plugins that breaks and lets you pin it to a known good version.
- Nicer UI to install and update plugins, including a git log for each plugin.
- Lazy loading of plugins. Not critical, but it does make a difference if you have a few slow plugins that you need occasionally or just a lot of plugins.
I use NeoVim. I used Vim previously and just know the built in basics very well.
NeoVim incorporating Lua as a first class language has allowed plugin authors to build plugins that are faster and better than plugins for Vim written in VimScript (or other languages like python/typescript which are much slower).
There is a strong community for neovim on reddit, youtube, etc and plugin authors do a nice job of building tools that work with each other.
Setting it up I agree is a pain, but once done its very little maintenance/work. Even when I've had to 'redo' my setup (eg switching package managers like vim plug to packer to lazy) its been easy and under 15 or so minutes.
I edit minor things in my config every few months. Everything flows quite nicely now and breaking changes are far less common than they used to be (at least among the plugins I use).
I haven't used Kakoune, but I've used emacs, Neovim, and Helix. I love the simplicity of Helix and how easy it is to get it up and running with language servers. Emacs and Neovim have amazing ecosystems, but I'm not willing to devote the time needed to keep my setup working and do the labor of installing and configuring so many plugins. I actually switched from emacs to a mix of VSCode and JetBrains IDEs (PyCharm, DataGrip) but I sometimes find myself copy-pasting blocks of text into emacs when I need to do anything fancy or repetitive. I used a Neovim integration for VSCode for a while but found it annoyingly buggy.
IDEs like VSCode and JetBrains seem to be in denial about coding being a text editing activity. Emacs and Neovim want you to take on a part-time job building and maintaining your own personal editor application out of a pile of spare parts. Helix to me is a very promising approach: a text editor that aspires to provide enough polished core features to be a productive coding environment.
FWIW it took effort for me to choose and curate my nvim plugins, but there's almost 0 time and effort invested in maintaining it.
Occasionally CoC will ask me to update it, that's running a single command. That's it, as long as you're not constantly looking for new tools and plugins (we've all been there), once you settle on your setup, there is no maintenance whatsoever.
Helix is very cool, and I liked playing around with it. But it doesn't support Copilot, which is an instant deal killer for a lot of people, myself included.
I'm sticking with Neovim, especially because I work close to a lot of embedded stuff where being handy with stock vim comes in handy quite frequently.
"For a lot of people"? I'm not saying your experience is invalid, I'm just curious how big the overlap of Codepilot users and potential Helix users is. I don't know anyone personally who likes Codepilot, and only a few who have used it at all. To me it still seems to be a niche (and probably copyright law violating) product.
Probably a lot of people, yeah. More than half of the developers I know use Copilot. The vast majority of those that do use it are (Neo)vim users, which should have plenty of overlap with Helix.
Also, I don't know what there is to like about Copilot. It fills in code based on what's around it more or less matching intent. It's basically a tool to fill in pieces that someone was going to write anyway, as far as I'm concerned.
I have used all three. Vim for ~5 years, then kakoune for 2 years, then helix for 2 months, and back to kak for 2 years (with no end in sight). Kakoune is my favorite and helix is very nice, and I would never go back to vim.
Vim:
+ ecosystem is nice. Plugins and matching keybinds in ACE/codemirror/whatever was cool for interop
+ having vi or vim on any Linux box is nice
- you have to have plugins for basic things like pcre, correct colors (csapprox), and ale
- at least when I stopped using vim, the multiple cursors plugin was nothing near as good as the other two. It was tacked on to a single-cursor editor, and you can tell
Hx (my knowledge is 1-2 years old):
+ felt completely natural coming from vim. If you use vim and don't want to warp your brain with new keybinds, try hx. It feels like vim+more. Kak feels like a different editor
+ many built-in features that require plugins in vim/kak
+ using LSP motions felt amazing
+ written in rust, which I love. The codebase is entirely readable and I contributed a patch after only about an hour first looking at it
- hx didn't have motions for ()/<>/... Which I've come to rely on. Kak has m which is like Vim's f(v% if f was multiline
- no advanced keybinds/bindsym in vim/map in kak. Config was toml so the most you could do was bind single chars to other single chars
- no plugin support, though I found myself not really longing for any plugins because so much comes by default
- occasional crashes due to off-by-one errors and .unwraps sprinkled around
Kak:
+ editing feels amazing. Like the text is directly connected to your brain. This is because basically every action gives you feedback. For example, in vim, t(dt) gives you a cursor move and then the text is gone. t(v%d gives you feedback but takes way more keys, but in kak, md immediately selects the entire bracket after m and deletes it after d. Having visual feedback *as a requirement* (not an option like Vim's visual mode) is amazing. I didn't use hx enough to know if it feels like vim or kak in this regard
+ plugins exist. Kak-lsp is nice. Scripting your own keybinds feels more natural because the scripting language *is* the keybinds, contrary to vim. Basically imagine every keybind is like Vim's but with a :normal before it
+ multisel feels compltetly natural. Not like an extension to what you're doing, but everything is multisel, and you just happen to have n=1 selection sometimes
+/- piping to external programs feels very natural. I have numerous scripts that take stdin and write to stout. In kak, I select whatever I want and just run |encode-url<ret> and it pipes every individual selection to my command and replaces them with my output. This is also bad because if I have 100 selections (not uncommon), it will spawn 100 shells to spawn my command 100 times
- people keep saying it doesnt have a scripting language, which is misleading IMO. There are try blocks, %{} groups, and commands that you need to learn about. Look at hx if you're interesting in no scripting language. It reads a toml config file and that's it.
- a little overreliance on shell. I don't even know if windows can run kak because it uses shell so much. On one hand it's nice because I know Shell. On the other hand, interop feels weird. You echo commands and kak reads your stdout and evaluates it. It's clever and cool, but something about it feels weird.
- keybinds don't behavibe like vim or hx. You have to retrain your muscle memory, but IMO it's worth it. Using vim now though is painful
I was using Kakoune for 3-4 years, and switched a year ago to Helix.
Kakoune is OK, but:
Some details of editing are too optimized for counting keystrokes in vim golf, less for thinking-free editing experience.
Configuring and extending text editor with shell scripts is ridiculous.
It's in C++. I want to be able to debug and submit changes to my most used dev tool and I don't want to be touching C++.
Having said that, I still miss the visual-mode-first experience of Kakoune (most moves in Kakoune change/modify selection, while Vim/Helix have visual mode instead).
Otherwise I think Helix already leaped over Kakoune in terms of functionality and polish, because it's just easier to contribute to (in Rust).
BTW. The difference between Vim and Kakoune/Helix is not that big. For basic Vim modes in shells and other tools, I don't really notice it. `hjkl` works all the same.
Agreed on all points. And one more issue with Kakoune: while delegating all windowing functionality to the terminal emulator probably sounds great to the editor implementer, for a user it is fucking annoying. An editor should be able to manage splits and tabs. It should have a basic concept of some kind of UI pop ups.
Kakoune can feel _amazing_ to use at times, but it is at the same time a case study on why brutalist minimalism isn't the best design goal.
I mean you definitely can manage splits and tabs and even pop up ui with tmux, just like you can extend kakoune by writing shell scripts with kakoune’s eldrich horror nesting of editor contexts. I just think both of those things are a huge pain in the ass to deal with.
"An editor should be able to manage splits and tabs. It should have a basic concept of some kind of UI pop.."
Couldn't disagree more.
Of course, it is currently necessary for apps themselves to handle splits, tabs, etc, because the windowing systems and terminals are so lacking.
But in an ideal world, the windowing systems would handle all that consistently, and the apps could just focus on their own domain, interacting with the windowing system as necessary.
It would be nice if this could be done by terminal multiplexers such as screen or tmux. Some users might not be able to depend on a window manager, i.e. if they're working with a physical VT100 terminal over a serial connection.
Helix is easier to jump into as it supports a lot of useful code editing features out of the box, but Kakoune has a more elegant and discoverable modal editing experience.
Kakoune is also possible to use not as the creator intended or foresaw, which Helix isn't. If someone has any tinkerer in them at all Helix will be an awful editor to use as they'll probably spot some thing they want or need and be unable to add it.
nvim. There isn't much software I can say that feels so comfortable to use for me.
A lot of people look at the learning curve and decide it's not worth the time investment, just so they can save time later on when they're more comfortable with it.
But to me it's not about time, it's about how smooth it feels to use, how I can translate thinking to typing/editing with the least friction possible, and nvim with my minimal set of plugins that I curated over years, that is it.
I've been using Kakoune as a daily driver for about 2 years now. It's an order of magnitude better than anything else I've tried (vim, neovim, vscode, atom, jetbrains, codeblocks, notepad++, etc).
Especially once you:
* enable LSP support
* memorize the keybinding
* get comfortable with the kakoune scripting language
The keybindings were a lot easier to memorize than VIM's because of how consistent they are. And they're a lot easier to "experiment" with when your memory is fuzzy because you get realtime visual feedback on what your key combinations are building up in memory before it executes.
It's fast, unbelievably fast - faster than I type no matter what I'm doing. I never wait for anything unless I'm shelling out to some "modern" build/lint/style tool with a script.
It works out of the box with tiled window managers (:new opens a new terminal, `kak -c lets you open a new window into an existing editor session, etc.).
I can seamlessly move between the system clipboard and buffers using `xclip`, which is the same pattern that lets me seamlessly move between _any unix tool_ and a buffer. I can type `!tree` and get the directory listing for a README.
I can `%s [][]bytes<ret>di[]Image` to replace all arrays of images with an explicit type. With LSP support, I can highlight all _references_ the the currently highlighted variable/object/w.e., then select the entire line each one is on and delete it in like 4 keystrokes.
It gives realtime feedback as I type commands so I can see what I'm selecting in a buffer.
Autocomplete is aware of everything from LSP and _every open buffer_, so you can open buffers full of context you'd like autocomplete to have access to even if LSP isn't able to infer it.
I can wire up custom commands for each file type using the scripting language in minutes, not hours, to do things like automatically run the language's auto formatter.
With LSP enabled, I can `gd` on any variable/object/function/w.e. and _immediately_ find myself looking at where it was defined. Even if that definition is the go standard library, Node core, some dependency down inside my node_modules or vendor directory, w.e.
With LSP enabled, I get the entire MDN library fact-checking my method signatures and helping me with autocomplete _in realtime_ as I type.
Some tips for people wanting to use kakoune:
Add this bash script to your PATH as `k`, it lets you open a new window into the current editing session from any terminal - so you can `cd` around the filesystem to look for files of interest and then open them in another terminal's editing session top copy stuff over and make autocomplete aware of its contents: https://gist.github.com/retrohacker/8920d056f4938e8dd263adac...
Take the contents of `:doc` and put it all into something like Anki (or just make flash cards for yourself). Learning the keybindings by heart is a small investment that will pay massive dividends.
Integrate LSP and take a moment to learn the different commands. I can't stress this enough.
Wait until about 6 months in to bother trying to learn the scripting language. The scripting language is pretty much what you've been using the entire time, you just write it down in a config file instead of typing it into a live session. The scripting language docs don't make any sense unless you already know kakoune, it's much easier to understand once you have a better feel for how kakoune works.
Once you learn the scripting language and have a good feeling for the default keystrokes, you can start mapping a bunch of your common workflows (`!` and `:` commands, buffers, etc) to unused keys, or keys you have no use for.
Here is my kakrc for reference, but keep in mind I change this fairly often as my workflows change across code bases:
I got quite annoyed with Neovim config at some point and tried out Kakoune, and ended up contributing some window splitting code to the main repo for Sway. I liked it quite a lot, but it's not built with Windows in mind so I ended up crawling back to Neovim. I'd be interested to hear of any Kakoune-like editors with better cross-platform support/design.
> Kakoune made me learn Perl ... Awk ... POSIX sh ... regexes
But these aren't great ergonomic tools, so it's not a good thing that Kakoune "requires" them, it's rather a testatment of how much it's lacking on its own
(though haven't used Kak since it's unfortunately not x-platform, the selection first paradigm is totally a superior UI to the hidden vim ways)
>so it's not a good thing that Kakoune "requires" them
It doesn't. Author learned them because they made plugins and complex custom commands. The configuration language allows embedding shell scripts but Kakoune provides a POSIX interface so can use whatever language you want for plugins. Regexes are needed to be productive utilizing the full extend of text manipulation provided. Can do without but you miss a big reason for using Kakoune in first place.
I've added quotes specifically for you - as you notice yourself, you do miss a lot by not using these things, so to use Kakoune properly you did need them
I take your point about any language (which is great), but then the foundation of that is broken - it excludes the most popular desktop OS Windows (besides its other flaws that might not be relevantf to Kak integration), that's why "forcing" to learn posix isn't an argument for
Odd choice of words. I'd say that perl, awk, regex etc are great ergonomic tools - if anything too ergonomic. The main problem with them - and the probable source of their bad reputations - is that the ease and comfort (the 'ergonomics') of just cobbling something together something that works and then throwing it out there does not encourage good engineering practices.
Do I need good engineering practices in my day-to-day text editing? Mostly not for what I do myself, but I'm grateful that the maintainers of the emacs packages I use have better tools to work with.
or something that works... sometimes, and is indecipherable, so all the "ergonomics" of the initial cobbling phase disappears to reveal how unergonomic this really is
I feel you've missed my point - 'ergonomics' literally means 'efficiency and comfort', not 'future maintainability'. Regex does comfort. AWK does it. If you need to do a specific thing right now, and you know them, then those tools are about as good as it gets. I'm not denying that those solutions will be horrible to grow and maintain, but that wasn't your point - that's why I said your choice of saying they weren't "ergonomic" was a bit odd. They are. That's the problem.
Most of the custom text editing operations I do on a daily basis only need to work once. For that, a Regex is very 'ergonomic'. If I were writing an emacs package, I'd probably use something better - something less ergonomic, but easier to maintain.
As an aside, I used to work in a machine shop and we had a well-designed system of pneumatic tubes throughout the warehouse powering spartan steel-handled drills that would give me calluses but reliably get the same jobs done the same way every day. At home, for the odd job I need to do, I use a cheap lithium drill with a nice grippy handle. Sometimes the ergonomic option is better because, right now, I just don't need to buy a compressor and run tubes through my house.
There is no comfort in poorly readable regex that seems to work, but really doesn't with a subtle bug.
And it's only efficient if you consider the time to write the bugged version, not the time to write the correct version
I'm currently using Kak for system configuration, limited shell scripting, and soon, learning Zig. (I use evil emacs for all of my heavy duty coding (lisp mostly))
Kak is such an elegant form of modal editing compared to Vim & Emacs. Selection first paired with feedback & suggestions gives Kak a discoverability emacs & vim simply do not approach. This also means you can pick up and learn Kak in a fraction of the time you'll learn the others. I recommend finding or creating a purpose for Kak if you're interested in the tools you use and how they can be made better.
112 comments
[ 4.8 ms ] story [ 385 ms ] thread> Small and understandable core.
> Proficiency with POSIX tools, and maybe even some programming languages other than sh.
> Structural regular expressions as a central way of text manipulation.
> With multiple selections created via regular expressions, acting upon regular expressions.
> Fresh take on the modal editing paradigm.
I wonder if the author has ever heard of vis[0] which imho fulfills far better each one of those premises
[0] https://github.com/martanne/vis
vis is cool but its structural regular expressions are much less easier to use since kakoune's give you feedback in real time. it is nice that vis actually has a lua API though.
Yes.
https://github.com/martanne/vis/wiki/Differences-from-Kakoun...
https://github.com/mawww/kakoune/wiki#onboarding
> which imho fulfills far better each one of those premises
Not very motivated for such a harsh critic..
> I wonder if the author has ever heard of vis[0] which imho fulfills far better each one of those premises
Same goes for Sam…
1. Vim is muscle memory for a lot of us. Something that is so similar but not quite the same just fucks with my brain. I have an easier time using stock Emacs bindings than Kakoune, as my brain is not in Vim mode while using it.
2. VS Code, Fat Visual Studio, IntelliJ, Emacs, most IDEs/text editors, fuck even Compiler Explorer have Vim plugins that range in quality from acceptable to fantastic. You can get a fix for your vim needs even in a disgusting corporate Windows crackhouse environment.
3. If you're a purist, Vim itself has a great ecosystem, and can be reasonably used for a lot of tasks.
But I never use vim by itself, I use it in other apps. And there's a perfectly good Helix plugin for VSCode, but I also use vim mode in Obsidian (since I'm constantly switching back and forth between Obsidian and VSCode) and there is currently no plugin for anything else. I need my code editor and my note editor to have the same controls, otherwise my brain gets confused.
Once a Helix or Kakoune plugin is created for Obsidian, I am switching straight away.
I fully agree – but why use two separate editors, then? (Full disclosure – I'm a long-time Emacs user, making most of my notes in Org-mode.)
Which one?
Oh... For my part, other binds are weird and less ergonomic from far. I'm vey used to vi-style: I mostly work in text mode (no GUI, no mouse) and I like to talk to my editor what I want...
https://www.dendron.so/
My editor stack has been Zellij, Helix and gitui as of late, and, there's still a few important things missing for me, but still working on it...
Stress on the good ol wrists and digits though? Not really sure. If there is a reason to switch, it’d be based on that.
My preferred layout is HHKB/Tsangan, a minor variant on QWERTY that replaces Caps Lock with Control, moves Esc to the number row, collapses F-keys into a number row layer, and moves Backspace down where backslash/pipe are and even with that standard keyboards can be frustrating (you don’t realize how hard standard Esc and Backspace positions are to reach until you’ve tried this layout). I can’t imagine what it’d be like if I were using DVORAK or something.
Swapping wasn't hard, but it sure wasn't easy. Did you find going from B -> C (-> D?) easier than A -> B?
For me, going from B -> C and C -> D (and then a long period of tweaking) was significantly easier than from A -> B.
I had an acquaintance that told how he had spent years investing in Dvorak. He came back to QWERTY because he got a job where he had to jump onto others computers on occasion. The friction he felt fighting against his muscle memory was more annoying than any benefit he got from the supposed better Dvorak layout.
I now use VSCode for 90% of my stuff and I use vim whenever I ssh into boxes or if I really need a quick edit from the CLI. But I keep vim totally stock, not a single thing in my dot file. There are aspects of my previous highly-customized and personalized vim setup that I miss - but I am free from the frustration of them not being there.
As I get older, freedom from frustration has become more important than the marginal improvements of customization for efficiency.
I'm incredibly skeptical, however, that VSCode has as-good of a vim emulation layer as evil-mode. Evil-mode is just fantastic. Customized Emacs w/ evil-mode gives me everything I'd get from a fancy IDE, and keeps my vim muscle memory intact for those times when I am using regular vim.
This has been my pattern for a decade and it's glorious. GLORIOUS, I tell you! Few things give me joy in computing like the balance in the Force that I've managed to strike between Emacs and vim
Using mnemonic key bindings is much friendlier than dozens of random key combinations. There's a popular key-chord package[1] that minimizes this discomfort, but without editing modes, users need to be concerned with the chords clashing with their actual text, which is absurd. Modes address this issue gracefully.
I still use some basic combinations like M-x, but I would be completely lost in Emacs if it weren't for evil-mode. <3
The thing with modal UIs is that you want to use them everywhere. So I also enable vi-mode in my shells, and in any application that uses readline.
[1]: https://www.emacswiki.org/emacs/KeyChord
[1]
I use the native one as it's a little less "pure" about VIM and integrates better with VSCode things. Overall it's less evil than evil. ;)
If I need to program, I just copy my Emacs configuration to that machine. I have never encountered a situation where I'm forced to use stock Emacs, or someone else's Emacs configuration. If I need to make a quick edit from the CLI, using plain Vim is fine, but I feel more "at home" with my own tweaks. None of these things are hurdles that would make me settle for an editor that someone else has preconfigured for me.
At the end of the day, this will depend on how important you find customizing your working environment to your liking. If you're fine with someone else making that decision for you, you'd probably find the stock configuration, or someone else's configuration, acceptable. If OTOH you have strong opinions about the way you want to use your editor, then the time and effort invested in configuring it and managing that configuration is not an issue.
This goes beyond just text editors, and applies to computing in general. Some people are fine with using stock software as it comes from the manufacturer. Most software, in fact, is not deeply configurable. Apple devices and software are wildly popular despite lacking configuration. But the reason we choose operating systems like Linux, and text editors like Vim and Emacs is precisely because they give us the freedom to use our computers in the way we want to use them, not as someone else thinks we ought to.
And also consider Colemak-DH over Dvorak.
If you're worried about having to relearn Vim commands, it's not a big deal. You're not remembering the key positions but the mnemonics, so "dta" means "delete to a" not some key positions. You'll be fine.
Oh man, this was so difficult for me with a split ortho keyboard. I realized that most of my bindings now i don't actually "know". It's 100% muscle memory.
I had to keep a keyboard handy to "do the thing i want on the unplugged keyboard" to see what the bind was. Kinda mind blowing to me hah.
I did switch to a BEAKL layout, and then to my own layout.
So maybe we learn things differently?
it was used against the fish shell for example. yet eventually it started getting acceptance. the same may happen with kakoune. i tried using it myself. i wasn't so much bothered by the changes. i had different issues. i got burned by kakoune overwriting a file without warning me. vim would not have done that. and i couldn't get over the fact that kak means shit in some languages. it will take some more effort to overcome that and give it another try.
1) Few people will have benefit of learning Dvorak. What benefits they see comes from learning how to properly touch type by forcefully breaking bad habits with their original (usually QWERTY) keyboard layout.
2) Switch to Colemak or any more modern layout that takes advantage of bigrams/trigrams better. Colemak is genuinely superior to QWERTY beyond just learning to touch type.
I used to type 170~ WPM on QWERTY. Sustained. By all means an accomplished typist. I learned Dvorak well enough to get back up to 120~ WPM but saw no real benefits of using it: I already knew how to touch type. But QWERTY was causing my hands to cramp up over time and so I was on the search for improving that. I gave Colemak a try and it was a great relief. I only type 150~ WPM on Colemak after some years of using it but the lack of pain from typing for long periods of time is worth the small hit to my typing speed.
Almost every single person I see who touts benefits of learning Dvorak was typing <60WPM in QWERTY and did not know how to properly touch type. The benefits they see weren't from using Dvorak: it was from finally learning how to touch type properly.
Apologies as I know Dvorak wasn't really the focus of your post here. But in an attempt to perhaps make it still relevant: change every now and then is good. It can break you out of bad habits you didn't know you had learned and sometimes open you up to new ways of accomplishing something. As other replies have mentioned - I'm a big fan of Helix and gave up Neovim for it.
Xah Lee wrote an analysis on why he believes Dvorak is better than Colemak: <http://xahlee.info/kbd/dvorak_vs_colemak.html> and he brings up the frequency of the "th" digram, which on Colemak is a bit of an issue due to the finger travel.
That's an absurd speed.
I can touch type on QWERTY, and last I measured I hovered at around 100 WPM on my best efforts. But TBH typing speed is really not something I'm concerned about. When I'm programming, accuracy is more important than speed, and I spend much more time thinking than actually typing. And when I'm writing prose, I also make pauses to rethink what I'm writing, and go back and forth, refining the text to match my thoughts. So even if I typed much faster, my overall speed of communication or programming wouldn't improve.
I also haven't had any discomfort after decades of typing on QWERTY keyboards. I find it hard to believe that a different layout would reduce discomfort more than using an ergonomic keyboard, with proper wrist support and posture.
Typing on an actually ergonomic keyboard (currently a Keyboardio Model01) is a much more significant comfort difference.
Both together scratches an itch that I recognize not everyone has, but if you do have that itch, scratching it feels damn good.
Speaking from my own personal experience, I learned to touch type (properly) on QWERTY first, but after a while I switched to Colemak. After yet another while, I switched to Dvorak, and have been using it for several years now. For me, Dvorak has been slightly more comfortable than Colemak (which, in turn, was much more comfortable than QWERTY); though I have to admit I’ve never experienced significant pain or cramps just from typing. In any case, I find both layouts to be a great improvement over QWERTY, and certainly not only because of touch typing.
There's always a handful of exceptions to every rule but by and large from my experiences in the altkey layout communities the people who touted Dvorak the loudest largely didn't know how to type properly before learning Dvorak and it was their first alternative layout learned. So it's colored my view a bit.
I have regularly typed for >8 hours/day - nearly every day - since age 8. The hand pains didn't really start until I was in my 20's.
With that I fully agree, but then again - in my mind that exactly is the value proposition of any non-QWERTY-layout.
I also agree that ergonomics is more important than peek throughput.
But you neglect the cost. The cost of ruining shortcuts in many applications and/or complex OS settings just to be able to type. There are workarounds and solutions for most but I haven't been convinced it is a net gain.
So in my opinion, stay and invest in QWERTY instead. Regarding ergonomics use a split ortholinear keyboard. I am in doubt any layout will be as liberating as that and orders of magnitude less investment in time.
Everytime I use or think of a staggered keyboard I'm amazed at the design. Put your right hand over the right hand of the keyboard as if to type, the columns kind of naturally go with your fingers - not bad at all really. Then do the same with your left hand and it is just a clusterfuck.
Though I do have to acknowledge two things, you can of course use and benefit from an alternative layout on an ortholinear keyboard as well. And the cost of only feeling at home on a bespoke keyboard (not that it is different enough for you to not be able to use a normal keyboard) isn't negligible depending on your situation either.
It's significantly less valuable, but still worth learning an alternative keyboard layout, though Dvorak specifically isn't nearly as good as modern alternative like Colemak or Workman.
Vim is incredible for every reason except its keybinds. Technically, you can remap them, but that quickly devolves into dependency hell... learning to type using the Workman layout is why I'm an Emacs user today. One of these days I'll get around to making a truly configurable modular editor...that will most likely be an Emacs config.
Its awesome to have so many choices so everyone can pick the system that best fits them. It also encourages better tooling that can fit on top of any of these like the Language Server Protocol, TreeSitter etc which benefit everyone.
Thanks to everyone for working on all these projects and tooling, its truly incredible.
[0] https://github.com/vscode-neovim/vscode-neovim
What would be ideal for me, but probably not possible in reality, is an editor that cannibalizes popular plugins. So, if a feature is sorely lacking, the plugins appear, but eventually the core functionality grows to replace the plugins. A new user installs the editor and gets a rich set of features that are battle-tested and built to work together. What seems to happen in practice with emacs and Neovim is that the core never gets any bigger, so a new user gets zero benefit from those decades of work, experimentation, and discovery, until they invest the time to integrate dozens of disparate packages into their own setup which they will have to maintain themselves over time.
The other "in practice" side is that without plugins the editor will never get as good as a properly (though painfully, though less painfully with some preconfigured distribution) configured alternative one with plugins
The maintainers are collaborating with the dev and hope to get a PR open sometime this upcoming year.
Vim bindings are not the most consistent, but they are ubiquitous. Every program that offers Vim mode has very similar keymap. If modal text editor deviates from them, it better be for good reason.
Kakoune bindings are very different from Vim, but they are provably and objectively [1] better, so that's fine. They are also more consistent and there is a clear idea behind the whole design. It's written down in documentation. You might prefer Vim or Emacs, but at least you can see that changes from well known Vim scheme are not made at whim.
Helix keymap feels like it was improvised without any thought behind it. „Let's take Kakoune binds and add back visual mode cuz I feel like it.” Currently, they are designed by committee in this GitHub issue[2]. I don't see any design notes and explanations why should I spend time learning Helix keymap.
[1]: https://github.com/mawww/golf [2]: https://github.com/helix-editor/helix/issues/165
I'm currently using VSCode, but I don't code a lot these days. If you are looking to explore a new paradigm like that, I would go with Emacs as a practical option (with vi bindings) and Acme as a way to open your mind (but not very practical).
That being said, Neovim, once you get it set up, is great. The biggest hurdle for me was the config, but if you just start from scratch and make a light config (mines about 200-300 lines, with LSP, hints, etc) you can get through it. And you never have to touch it again, since most likely you configured it in a way you like. Well unless you wanna add the occasional plugin. There are also distros of Neovim that contain a fully baked IDE-lite experience, but honestly those have extremely complicated config, and often IME don't feel nice and light.
It's definitely not for everyone. There is that time investment to get started, but it's definitely been worth it for me.
My config: https://github.com/wrapperup/nvim-config
That was the issue for me, there actually is quite a bit of churn in the Neovim plugins ecosystem compared to VSCode (Packer vs Lazy for plugin management is just the latest iteration). I used to have Neovim plugins all built out but the churn was too much for me.
Small customized config also means smaller and more precise changes. I haven't touched mine in quite a long time, only usually to add that cool trick or plugin that pops up every so often.
I've used vim-plug for over a decade and it's been working fine. Yes there has been a lot of churn within some plugins, but overall it hasn't been that bad in my opinion.
And with lazy tracking plugin versions in a lock file, it's easy enough to pin plugins to a known good version whenever something breaks.
(I finally rewrote my entire config, and lazy is vastly better than vim-plug. I should've done so sooner.)
What's better about it? I ask because I've been using `Plug` since I switched from pathogen (what feels like) an eternity ago and I don't really know any reason to switch because it just sort of works...? Every few years or whatever I'll overhaul the config (not a choice but it just sort of happens) and I'm curious whether switching plugin management plugin has a point.
- You can specify plugins dependencies, instead of having everything in a big list.
- You can separate each plugin setup/configuration into separate files.
- It tracks plugin versions in a lock file that you can commit into git. Makes it easy to identify plugins that breaks and lets you pin it to a known good version.
- Nicer UI to install and update plugins, including a git log for each plugin.
- Lazy loading of plugins. Not critical, but it does make a difference if you have a few slow plugins that you need occasionally or just a lot of plugins.
- Profile plugin startup times in a nice way.
NeoVim incorporating Lua as a first class language has allowed plugin authors to build plugins that are faster and better than plugins for Vim written in VimScript (or other languages like python/typescript which are much slower).
There is a strong community for neovim on reddit, youtube, etc and plugin authors do a nice job of building tools that work with each other.
Setting it up I agree is a pain, but once done its very little maintenance/work. Even when I've had to 'redo' my setup (eg switching package managers like vim plug to packer to lazy) its been easy and under 15 or so minutes.
I edit minor things in my config every few months. Everything flows quite nicely now and breaking changes are far less common than they used to be (at least among the plugins I use).
My vim config if you're curious (along with the rest of my dotfiles): https://github.com/sbernheim4/dotfiles/tree/master/vim
IDEs like VSCode and JetBrains seem to be in denial about coding being a text editing activity. Emacs and Neovim want you to take on a part-time job building and maintaining your own personal editor application out of a pile of spare parts. Helix to me is a very promising approach: a text editor that aspires to provide enough polished core features to be a productive coding environment.
Occasionally CoC will ask me to update it, that's running a single command. That's it, as long as you're not constantly looking for new tools and plugins (we've all been there), once you settle on your setup, there is no maintenance whatsoever.
Honestly: I use Jetbrains IDEs now. It is worth having the little integrated tools, like the debugger, etc.
I have a nice NeoVim setup but it gets used less and less now.
I'm sticking with Neovim, especially because I work close to a lot of embedded stuff where being handy with stock vim comes in handy quite frequently.
Also, I don't know what there is to like about Copilot. It fills in code based on what's around it more or less matching intent. It's basically a tool to fill in pieces that someone was going to write anyway, as far as I'm concerned.
Vim:
Hx (my knowledge is 1-2 years old): Kak: Kak is greatKakoune is OK, but:
Some details of editing are too optimized for counting keystrokes in vim golf, less for thinking-free editing experience.
Configuring and extending text editor with shell scripts is ridiculous.
It's in C++. I want to be able to debug and submit changes to my most used dev tool and I don't want to be touching C++.
Having said that, I still miss the visual-mode-first experience of Kakoune (most moves in Kakoune change/modify selection, while Vim/Helix have visual mode instead).
Otherwise I think Helix already leaped over Kakoune in terms of functionality and polish, because it's just easier to contribute to (in Rust).
BTW. The difference between Vim and Kakoune/Helix is not that big. For basic Vim modes in shells and other tools, I don't really notice it. `hjkl` works all the same.
Kakoune can feel _amazing_ to use at times, but it is at the same time a case study on why brutalist minimalism isn't the best design goal.
I don't doubt there's something, I've just never encountered it.
Couldn't disagree more.
Of course, it is currently necessary for apps themselves to handle splits, tabs, etc, because the windowing systems and terminals are so lacking.
But in an ideal world, the windowing systems would handle all that consistently, and the apps could just focus on their own domain, interacting with the windowing system as necessary.
A lot of people look at the learning curve and decide it's not worth the time investment, just so they can save time later on when they're more comfortable with it.
But to me it's not about time, it's about how smooth it feels to use, how I can translate thinking to typing/editing with the least friction possible, and nvim with my minimal set of plugins that I curated over years, that is it.
Especially once you:
* enable LSP support
* memorize the keybinding
* get comfortable with the kakoune scripting language
The keybindings were a lot easier to memorize than VIM's because of how consistent they are. And they're a lot easier to "experiment" with when your memory is fuzzy because you get realtime visual feedback on what your key combinations are building up in memory before it executes.
It's fast, unbelievably fast - faster than I type no matter what I'm doing. I never wait for anything unless I'm shelling out to some "modern" build/lint/style tool with a script.
It works out of the box with tiled window managers (:new opens a new terminal, `kak -c lets you open a new window into an existing editor session, etc.).
I can seamlessly move between the system clipboard and buffers using `xclip`, which is the same pattern that lets me seamlessly move between _any unix tool_ and a buffer. I can type `!tree` and get the directory listing for a README.
I can `%s [][]bytes<ret>di[]Image` to replace all arrays of images with an explicit type. With LSP support, I can highlight all _references_ the the currently highlighted variable/object/w.e., then select the entire line each one is on and delete it in like 4 keystrokes.
It gives realtime feedback as I type commands so I can see what I'm selecting in a buffer.
Autocomplete is aware of everything from LSP and _every open buffer_, so you can open buffers full of context you'd like autocomplete to have access to even if LSP isn't able to infer it.
I can wire up custom commands for each file type using the scripting language in minutes, not hours, to do things like automatically run the language's auto formatter.
With LSP enabled, I can `gd` on any variable/object/function/w.e. and _immediately_ find myself looking at where it was defined. Even if that definition is the go standard library, Node core, some dependency down inside my node_modules or vendor directory, w.e.
With LSP enabled, I get the entire MDN library fact-checking my method signatures and helping me with autocomplete _in realtime_ as I type.
Some tips for people wanting to use kakoune:
Add this bash script to your PATH as `k`, it lets you open a new window into the current editing session from any terminal - so you can `cd` around the filesystem to look for files of interest and then open them in another terminal's editing session top copy stuff over and make autocomplete aware of its contents: https://gist.github.com/retrohacker/8920d056f4938e8dd263adac...
Take the contents of `:doc` and put it all into something like Anki (or just make flash cards for yourself). Learning the keybindings by heart is a small investment that will pay massive dividends.
Integrate LSP and take a moment to learn the different commands. I can't stress this enough.
Wait until about 6 months in to bother trying to learn the scripting language. The scripting language is pretty much what you've been using the entire time, you just write it down in a config file instead of typing it into a live session. The scripting language docs don't make any sense unless you already know kakoune, it's much easier to understand once you have a better feel for how kakoune works.
Once you learn the scripting language and have a good feeling for the default keystrokes, you can start mapping a bunch of your common workflows (`!` and `:` commands, buffers, etc) to unused keys, or keys you have no use for.
Here is my kakrc for reference, but keep in mind I change this fairly often as my workflows change across code bases:
> Kakoune made me learn Perl ... Awk ... POSIX sh ... regexes
But these aren't great ergonomic tools, so it's not a good thing that Kakoune "requires" them, it's rather a testatment of how much it's lacking on its own
(though haven't used Kak since it's unfortunately not x-platform, the selection first paradigm is totally a superior UI to the hidden vim ways)
It doesn't. Author learned them because they made plugins and complex custom commands. The configuration language allows embedding shell scripts but Kakoune provides a POSIX interface so can use whatever language you want for plugins. Regexes are needed to be productive utilizing the full extend of text manipulation provided. Can do without but you miss a big reason for using Kakoune in first place.
I take your point about any language (which is great), but then the foundation of that is broken - it excludes the most popular desktop OS Windows (besides its other flaws that might not be relevantf to Kak integration), that's why "forcing" to learn posix isn't an argument for
Do I need good engineering practices in my day-to-day text editing? Mostly not for what I do myself, but I'm grateful that the maintainers of the emacs packages I use have better tools to work with.
or something that works... sometimes, and is indecipherable, so all the "ergonomics" of the initial cobbling phase disappears to reveal how unergonomic this really is
Most of the custom text editing operations I do on a daily basis only need to work once. For that, a Regex is very 'ergonomic'. If I were writing an emacs package, I'd probably use something better - something less ergonomic, but easier to maintain.
As an aside, I used to work in a machine shop and we had a well-designed system of pneumatic tubes throughout the warehouse powering spartan steel-handled drills that would give me calluses but reliably get the same jobs done the same way every day. At home, for the odd job I need to do, I use a cheap lithium drill with a nice grippy handle. Sometimes the ergonomic option is better because, right now, I just don't need to buy a compressor and run tubes through my house.
This isn't about future maintainability
Kak is such an elegant form of modal editing compared to Vim & Emacs. Selection first paired with feedback & suggestions gives Kak a discoverability emacs & vim simply do not approach. This also means you can pick up and learn Kak in a fraction of the time you'll learn the others. I recommend finding or creating a purpose for Kak if you're interested in the tools you use and how they can be made better.
Even more hindsight on Vim, Helix and Kakoune - https://news.ycombinator.com/item?id=36427267 - June 2023 (115 comments)
Why Kakoune – The quest for a better code editor (2016) - https://news.ycombinator.com/item?id=36424256 - June 2023 (89 comments)
More hindsight on Vim, helix and kakoune - https://news.ycombinator.com/item?id=36066347 - May 2023 (1 comment)
Kakoune Code Editor - https://news.ycombinator.com/item?id=29975052 - Jan 2022 (170 comments)
Kakoune, a punk-rock text editor - https://news.ycombinator.com/item?id=24716187 - Oct 2020 (2 comments)
What you could steal from the Kakoune code editor, and get away with - https://news.ycombinator.com/item?id=24685267 - Oct 2020 (94 comments)
Kakoune – A Modal Text Editor - https://news.ycombinator.com/item?id=19313794 - March 2019 (58 comments)
Why Kakoune – The quest for a better code editor - https://news.ycombinator.com/item?id=17781780 - Aug 2018 (45 comments)
Why Kakoune – The quest for a better code editor - https://news.ycombinator.com/item?id=13165919 - Dec 2016 (327 comments)
Kakoune: a better code editor - https://news.ycombinator.com/item?id=13152499 - Dec 2016 (2 comments)
Kakoune – An experiment for a better code editor - https://news.ycombinator.com/item?id=10484653 - Oct 2015 (34 comments)
Mawww's experiment for a better code editor - https://news.ycombinator.com/item?id=9764028 - June 2015 (15 comments)