Why Kakoune – The quest for a better code editor (2016) | Hacker News Reader

Why Kakoune – The quest for a better code editor (2016)

kakoune.org

179 pointsr3trohack3r89 comments

Related ongoing thread:

Even more hindsight on Vim, Helix and Kakoune - https://news.ycombinator.com/item?id=36427267 - June 2023 (3 comments)

I spent a while trying Kakoune years ago and I have one minor complaint and one major complaint. Leading off with the minor complaint (because it’s more annoying than severe): it is designed for multiple cursors editing as the default, rather than single. That is, many of the normal movement operations (such as search) have the side effect of leaving behind extra cursors, like little breadcrumbs, that take an extra keystroke to dismiss.

Perhaps this makes sense for people who spend all day doing large-scale edits on highly structured files but it makes no sense for the kind of everyday editing that I do. Most of my time is spent either entering brand new text in bulk at the end of the file, or jumping around and making one-off changes via searching. When I want to do larger scale edits (I use vim, the editor kak was intended to succeed), I reach for :%s///gc to do confirmation-based global substitutions (or sometimes :g//s///gc instead of %s).

So I really don’t see the advantage of the multiple cursors approach, especially given that the files I’m working with are thousands of lines long. That is far too long to get any visual feedback benefit to using multiple cursors for whole-file substitutions.

Now on to the major complaint. For some reason, the developers decided to buck the trend of plugin-based editors by not including a built-in scripting language with a nice API. Instead, people wanting to extend Kakoune are expected to write bash scripts (!?).

Sorry, this is a colossal mistake that dooms the editor to irrelevance for the foreseeable future. They would have been far better off just picking a nice scripting language (how about Python, Ruby, or Lua) and building a really clean, sensible API for it. Bonus points for building in a package manager that can browse, fetch, install, and update plugins automatically. This is the one massive area of weakness for vim (VimScript? Ugh!) and they missed the boat!

As an alternative to gc you can page through selections with parens and alt-space to dismiss individual selections.

its also easier to compose filters, eg matching all lines that contain regex A and B regardless of order. doing that with vim regex is kind of annoying and it gets programming worse the more filters you need to add

Also its not bash specifically. You can send kak commands to the kak session from any programming language. As an example kak-lsp is in rust

As an alternative to gc you can page through selections with parens and alt-space to dismiss individual selections.

And that’s great, it means kakoune is capable of accomplishing the same task via an equivalent multiple-cursors trick.

But it’s not the way my mind works. It forces me to go through and prune the set of cursors before I start making the substitution. I don’t want to do that! I want to write the text of the substitution first (for the common case) and then y or n to yay/nay each substitution because often I don’t know (and don’t want to think about) everything my search pattern matched.

its also easier to compose filters, eg matching all lines that contain regex A and B regardless of order

I can count on one hand the number of times I really needed to do that in the two decades I’ve been using vim.

This is really the crux of the issue with Kakoune. It takes the good enough philosophy of vim’s composable count-motion-commands and tries to achieve apotheosis with a visual-motion-multiple-cursors scheme. In search of the perfect tool to let an octopus to edit the file everywhere at once, it leaves us humans behind. It also ignores the lessons of “Worse is Better” [1] in pursuit of philosophical purity.

[1] https://en.wikipedia.org/wiki/Worse_is_better

> That is, many of the normal movement operations (such as search) have the side effect of leaving behind extra cursors, like little breadcrumbs, that take an extra keystroke to dismiss.

Uh, no? Unless you’re talking about undo which can indeed be annoying in that way when undoing a multicursor edit.

In particular, search with / and its modified versions does not change the number of cursors, and neither does the next occurrence command, n. You have to explicitly say N (that is <s-n>) to add a new selection at the next occurrence rather than move the current one there, or use s and friends which are specifically geared to act on each match within the current selection(s).

Are you sure you aren’t pressing something you shouldn’t be out of (Vim) habit?

Perhaps it’s changed since the last time I used it, but I do strongly recall it adding multiple cursors with regular n. Those cursors might not have been “live” for editing, but they were still there to distract me.

Nothing I can find about that in the changelog, but it’s possible. (Side note: “Development version: <a-u> and <a-U> now undo selection history.” Finally.)

My normal workflow these days is select first match with /, then N to accept match and continue to the next one or n to reject and continue; then edit all at once. (For me, the principal advantage of this over standard find-and-replace is that the edit doesn’t need to be restricted to the inside of the occurrence—for a bulk code edit, I often can’t quickly write a regexp for what I need to modify but can write one for something predictably close to it.)

Now that I’m thinking about it, your preferred workflow of confirming each replacement separately can be replicated like this for literals: use / to select first match, then Q, c, enter replacement, <esc>, Q. Then n to go to second match, q if you want to replace, n for third match, etc. (Here Q starts then ends recording a keyboard macro, q plays it back.) More complex replacements and regexp groups will be trickier but possible. (E.g. for s/whatever/before&after/ set up the replacement with /, whatever, <enter>, Q, i, before, <esc>, a, after, <esc>, Q.)

And now I’ve changed my mind on keyboard macros which I had thought were a silly feature for Kakoune. Hah.

That's probably because you confused Vim and Kakoune key bindings.

Kakoune

- n: next match

- alt+n: previous match

- shift+movement: extend selection by movement

Vim

- n: next

- shift+N: previous match

So if you press shift+N as you are used from vim, you start adding a lot of selections instead of going to previous match. I believe this difference is the most confusing for people who switch from Vim to Kakoune.

Kakoune is scripted over IPC, not bash scripts. The configuration language has some built in functionality for embedding bash scripts, and for smaller plugins or one-off personal customization, yeah you can do everything in a bash script.

But absolutely nothing forces you to implementing plugins as shell scripts! kak-lsp, which provides great integration with language servers, is written in rust. Peneira, a fuzzy finder tool, is implemented in python. People have written libraries for various languages that make interfacing with kakoune from your language of choice quite convenient.

The decision to make all extension functionality work over IPC instead of an embedded scripting language means everything that the editor is capable of can be controlled by any piece of software over a thoughtfully crafted and well-documented interface. Also the extensions people write for kakoune end up also serving as general purpose utilities that can be integrated into stuff other than kakoune.

I've always considered kakoune's approach to extensibility the main selling point of the editor. It has quite phenomenal plugin support for such a niche editor, and it's way easier to make your own plugin than it is with other editors because of how streamline the API is.

This sounds great, and on this alone I will give it a look.

You don't have to use VimScript, you can write your Vim plugins in Python if you wish.

One massive thing you lose with multiple cursors versus macros is you lose the ability to perform the same action across multiple files. Like you said, some multi cursor stuff is more useful to developers more focused on large-scale rewrites and refactors. However I argue macros are even more useful, because they can be saved and replayed across many files (even globally and automatically with just a few commands).

Kakoune has macros: https://github.com/mawww/kakoune/blob/master/doc/pages/keys....

I find this part very compelling

    vi basic grammar is verb followed by object; it’s nice because it matches well with the order we use in English, "delete word". On the other hand, it does not match well with the nature of what we express: There is only a handful of verbs in text editing (delete, yank, paste, insert… ), and they don’t compose, contrarily to objects which can be arbitrarily complex, and difficult to express. That means that errors are not handled well. If you express your object wrongly with a delete verb, the wrong text will get deleted, you will need to undo, and try again.

    Kakoune’s grammar is object followed by verb, combined with instantaneous feedback, that means you always see the current object (In Kakoune we call that the selection) before you apply your change, which allows you to correct errors on the go.

Unfortunately, I'd rather see this as an alternative input mode in vim/vscode/nvim than separate editor, so I won't need to throw away all knowledge/plugins/dotfiles accumulated over time, than switching to completely new editor. Baggage is hard.

I love the way he is basically modelling the way we interact with an editor as a grammar, or in mathematical terms. It's so interesting what kinds of designs you can come up with when you can successfully apply a different way of thinking about it.

Here is an interesting take on why the kakoune approach may not be an improvement over vim. Definitely well thought out.

https://github.com/noctuid/dotfiles/blob/master/emacs/editin...

As a heavy user of neovim who's been curious about the "noun-verb" approach to modal editing, this link was an excellent read!

Emacs has Meow which implements model editing with the Kakoune grammar:

https://github.com/meow-edit/meow

+1 for Meow. Vim doesn't make sense to me, but Meow does.

I dig this too. It's what I loved about Quicksilver - it had simple grammar that went direct object, verb, (optionally) indirect object. That tied nicely into the plugin system, which gave it tremendous flexibility. Successors like Alfred, Google Bar and Raycast are trying to recreate the unix command line and it doesn't work nearly as well.

Yes Quicksilver was very intuitive to work with, wonder why these new tools won't replicate the same behavior?

What's Quicksilver?

https://qsapp.com/manual/Introduction/#concepts-and-terminol...

You can get this to some extent with visual mode in (neo)vi(m).

The point is not the immediate visual feedback, but change "direction". Delete 3 words is dw3 vs 3Wd.

To some extent this is similar to common SQL criticism of order of SELECT x FROM y, where some people say that FROM y SELECT y would be more clear.

  ctrl-v 3w d
  shift-v 3j y
  v ib c

etc

don't you mean d3w?

You're right, typo :(

People say this about data.method() vs function(data) and about PowerShell using Verb-Noun when they want Noun-Verb. It's pretty clearly either a personal preference, or a thing where different contexts read better one way or the other.

Why can't we make things which work either way?

After having tried both, I prefer verb-object for editing operations any day. Especially since its more natural to add a number for repeating. And its excellent for macros.

The first part of this https://karthinks.com/software/fifteen-ways-to-use-embark/ also talks about how inverting action and object can be useful, and how Emacs's embark package makes it possible to even go back and forth between object and action as needed.

There are a lot of operations in vim that I don’t need or want to see the selection. Sometimes it would be useful, and if I think so, I use visual mode instead.

I tried using Kakoune as a daily driver for a while. I still bust it out now and then when there's something I want to do that would _really_ benefit from multiple cursors or structured regular expressions, but there's things that made me ditch it as my main editor:

1) Lack of windowing. I understand the pitch of radical simplicity by leaving this to the terminal editor, but it's just annoying as shit trying to write windowing configurations for different terminal editors. Something like making a window split and hopping between them shouldn't feel hacky and weird.

2) Extending the editor with Kakscript. Posix shell scripting is already something I do as little as possible, it's pretty much the worst programming language I can think of. Scripting kakoune uses shell scripting but it's far even worse, you descend into some weird un-debuggable eldritch horror mess of nested blocks of sh and eval mixing shell script semantics with kakoune editor state semantics.

Actually editing text with it feels amazing, though. It's like the yin to Emacs' yang.

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)

If kakoune sparks your interest, you might also want to check out Helix, a new editor inspired by Kakoune in some parts

What does Helix do that Kakoune doesn't?

From: https://helix-editor.com/

> Mainly by having more things built-in. Kakoune is composable by design, relying on external tooling to manage splits and provide language server support. Helix instead chooses to integrate more. We also use tree-sitter for highlighting and code analysis.

Here's a good comparison of the two. https://news.ycombinator.com/item?id=29976369

A prominent Kakoune contributor wrote up a great blog post exploring that question here: https://phaazon.net/blog/more-hindsight-vim-helix-kakoune

I switched from Kakoune to Helix after using Kakoune for a few years. Helix, to me, is everything i loved about Kakoune but with better defaults. It being in a language i love also is fun, as i almost immediately forked it and changed a few things - handy when they're still figuring out plugins.

Works on Windows

Discussed a few times:

More hindsight on Vim, helix and kakoune - https://news.ycombinator.com/item?id=36066347 - May 2023 (1 comment)

Helix 23.03 - https://news.ycombinator.com/item?id=35384691 - March 2023 (93 comments)

Helix 22.12 - https://news.ycombinator.com/item?id=33890655 - Dec 2022 (40 comments)

Helix: Post-Modern Text Editor - https://news.ycombinator.com/item?id=33494840 - Nov 2022 (166 comments)

Helix: A Neovim inspired editor, written in Rust - https://news.ycombinator.com/item?id=33147270 - Oct 2022 (306 comments)

Helix: A post-modern text editor - https://news.ycombinator.com/item?id=33039390 - Sept 2022 (2 comments)

Helix, Terminal Modal Editor - https://news.ycombinator.com/item?id=30847041 - March 2022 (2 comments)

Helix 0.5 released (Kakoune like terminal text editor) - https://news.ycombinator.com/item?id=29043889 - Oct 2021 (2 comments)

Helix: a post-modern modal text editor - https://news.ycombinator.com/item?id=27358479 - June 2021 (365 comments)

FWIW:

I tried Helix maybe about 6 months ago. It was pretty good, but there were things I do regularly in vim that I couldn't do in Helix, and the obvious way to do it in Helix didn't work (but it did in Kakoune when I tried that).

I mentioned this on whatever chat was listed on Helix's website as the place to go, and everyone there was open to making the obvious thing work, so I'm guessing Helix will get there at some point, but I don't want to use it now. Certainly given the relative momentum of the two projects Helix should get there some day.

Helix is awesome but have been disappointed by the core devs stance toward integrating some form of copilot. It's really difficult to use an editor that doesn't support it at this point.

What stance is that? Last I checked they were still figuring out how to extend the editor in general.

Reading this thread, I really like the idea of an IPC mechanism like Kakoune uses (and Neovim has IIRC)

If this were the case, integrating copilot or other ao tools would become pretty straightforward!

Yeah, that's basically the case. They don't have a plugin system, afaik it's still in the planning phase. They have LSP support, but copilot is a non-standard kind of LSP, and last time I looked the devs weren't interested in doing the integration work needed to get it all working nicely.

Can't say I blame them, it's their project after all. Just frustrating because I would totally use helix if not for the lack of that one feature. I actually still use it, but just as a quick way to make edits in the CLI, and not for full time dev. It's a great editor and project nonetheless.

Came to post this myself. What I love about Helix is that it just works out of the box. Install your toolchain and LSP and off you go. I absolutely do not want to have to write my own Vim config, or install some tool that configures a ton of stuff I don't understand.

The site makes a surprisingly compelling pitch to me, a grumpy and set in his ways vim/Linux user.

But, I don’t know. It is hard to overcome the fact that vi clones have been around for a bazillion years, will almost certainly outlive all of us, and will always be in every repo.

I don't usually feel the need to spread religious truths to the masses, but I'd be happy to know to that it was because of me that someone learned that the best vi(m) really is emacs in evil-mode.

> vi clones

This is the problem with moving off vi motions: you can get vi motions almost everywhere. Jetbrains, check, Visual Studio, check, vscode, check, sublime, check, firefox, check. The best I found for Kakoune (which I do significantly prefer) was an approximation of it for vscode, and nothing else.

I tried vim bindings in VSCode but I couldn’t stand them, it was right inside the uncanny valley for me.

What didn't you like about it?

Typically I use vim+tmux, so I should have also probably set up some additional extension to add a tmux-like panel change shortcut, so I could save-and-run like I normally would on the command line.

It also didn’t seem to handle Jupyter cells well. I forget exactly, but sometimes it would jump from one panel to another instead I think?

There is always something once in a while that steals the focus from the text and forces you to click back.

> It is hard to overcome the fact that vi clones have been around for a bazillion years, will almost certainly outlive all of us, and will always be in every repo.

Vi's ubiquity & longevity are good reasons to learn vi as at least a backup.

But, I don't think it'd be worth limiting yourself to plugin-less, unimproved vi just because there are some circumstances you won't be able to use your personalised setup. -- Since you'll be using your own configuration 99% of the time, I don't see the above as all that relevant for using something like kakoune.

I have tried my hand at Helix, a Kakoune-derivative, but I'm immensely bothered by the selection re-drawing as I move around: it creates visual noise. When I move, I just want to move; when I act, I just want to act. The problem of "maybe I wanted to delete 4 rather than 5 words" tends to not come up often enough to demand a solution as common programming notational practice tends to establish very obvious boundaries, e.g. df= (delete to the assignment operator), dfP (delete to first capital P, where maybe I'm renaming a method getFilePath with my cursor on the character 't'), d$ (delete to end of line), etc

I love kakoune's client-server design. I can open multiple terminal windows instead of terminal splits and panes (which I can never remember the shortcuts).

My main gripe is the extension model. Plugins run in a separate process which interacts with the editor by printing kakoune commands to standard output. Marshalling data and proper string escaping is a pain. Not to mention that many plugins are in bash, because it's the minimum common denominator.

For those of you that use VS Code, there is a plugin[1] that follow a lot of the Kakoune grammar but doesn't try to emulate fully, opting instead for better integration with vscode. I have been using it for a few years after using Kakoune for a few and then trying and failing to make my own Kakoune emulation mode for vscode.

[1]: https://github.com/71/dance

Using Dance as well for VSCode development. It's decent, albeit that the README could be more helpful.

There is a book from 1984, The Unix Programming Environment, by Brian Kernighan and Rob Pike.(https://archive.org/details/UNIXProgrammingEnvironment)

It is pretty much how I use the computer today, with few improvements with emacs and tmux. As I am teaching my daughter how to use cat/cut/grep etc, I am doing so truly thinking that this is the best way to use a computer in 2023.

The other day I was teaching her few shortcuts ^P and so on, I thought that maybe its time to re-think this whole cursor and keybinds thing. With apples vr magic goggles maybe someone can make an editor that I can follow code and write text and have 50 chats with some llm discussing various parts of the code I am working on.

All editors are limited by monitor space, the linux kernel style guide still has 80 column recommendation (not a hard limit since 2020), the way we jump into and out of code, or we step into thing, all are very limited and are pretty much the same since 1984.

I hope soon we have tooling like in the Hackers movie (https://www.imdb.com/title/tt0113243/) and use our eyes more to be able to follow code and systems.

The complexity of the systems has increased (e.g. cloud, hundreds of services, even LSP, tons and tons of boilerplate and generated code), but our tools are stuck.

I primarily used Kakoune for 2 months a few years ago. I loved its featureful regex engine which made certain macros much MUCH easier to write than Emacs functions. I also loved the selection-first editing model and have reimplemented that in Emacs and VS Code. But Kakoune was far too basic for me to get much serious C++ work done. You have to use external TUIs and CLIs constantly, and obviously those all have no integration with your Kakoune configuration.

Kakoune has some good ideas, eg. piping commands into it and having the editor immediately execute them is a really good one. Reminiscent of acme for Plan9, which exposes virtual files for its buffers and to receive commands, which makes it really convenient to develop tools for it.

That all being said, Kakoune simply doesn't offer enough for me to use it over vim. One of the first things I always see presented is multi-line-editing, a feature that could, maybe, come in handy once or twice a month for me. Comparing that to the simple fact that vim matured for over 30 years, and the sheer size of it's ecosystem, and switching to another modal terminal based editor is a really hard sell.

The object-verb syntax is a not a selling point to me, because I can have the exact same "preview" effect by using a vim plugin like easymotion:

    d<leader><leader>w

and I can see exactly to where it will delete before any changes happen to the buffer.

What I like about kakoune is that it suggests commands, making it more discoverable.

You can install vim plugins that do this, but kakoune doesn't need configuration to do this.

helix is also nice, and inspired by kakoune.

I feel using vim keybindings with VSCode to work best for me, for the work that I do.

Having another modal command-line editor like vim just doesn't appeal to me. However, this is a good concept.

Having this around over vim, with a well-established and mature ecosystem - is a hard sell..

Good luck.

Modal editing? Larry Tesler would not have approved https://en.wikipedia.org/wiki/Larry_Tesler

Nah. I don't think so.

When it comes to modal workflows, there's a tradeoff to be made between intuitiveness and efficiency that comes with lots of practice.

I don't use modal text editors anymore. But I get how modes can be useful and pleasant to have.

No modes means modifier keys for the most common actions which means Emacs pinky.

is there a thing like rlwrap or "kakkeys" for zsh (or in the browser like vimium)? i use kak as my main editor, but i don't like to mentally switch to vi keys for anything else every time.

Actually yes. Its named Krabby

for zsh: https://github.com/mawww/kakoune/wiki/zsh-zle

How do you edit a file on another machine with Kakoune? With emacs you use tramp, for example.

I haven't done this, but I believe you can use Kitty to edit remotely with Kakoune.

Is there a way to get kakoune working inside of JetBrains IDEs? Primarily CLion?

Anyone know the font in those videos? I think it looks pretty good.

Seems to be https://github.com/zshoals/Dina-Font-TTF-Remastered.

Source: https://www.reddit.com/r/kakoune/comments/rixopl/do_you_know...

Thanks!

Stop trying to make Kakoune happen, it's not going to happen.

the problem with all these hipster vims is that it's too late in the game, vi is everywhere you're going to be remoting into and these are only going to be on your localhost, not even off a fresh install. your muscle memory might as well carry over, same reason evil mode is the only modal extension for emacs that matters and QWERTY is the only keyboard layout for sane people

That massively depends on how often you remote into machines. It's also the same logic for using bash instead of zsh, a battle that zsh is winning - it turns out that learning one does not prevent learning both.

With recent integration of Copilot Chat in vscode, I’m less inclined to use Neovim or any terminal based editor. I think terminals had a time and place, but it’s time we moved on to tools that are more user friendly and provide better features.

TUI vs GUI seems orthogonal here, there are Copilot plugins for Neovim. Microsoft deciding what capabilities to make exclusive to its editor GUI is just vendor lock-in, not a fundamental refutation of the paradigm of modal TUI editors.

There's no reason why GUI tools can't embrace modal editing.

Also no reason terminal editors have to be modal, e.g. pico/nano

> I think terminals had a time and place, but it’s time we moved on to tools that are more user friendly and provide better features.

The terminal is not an impediment to "better features", and "user friendliness" is purely a subjective matter.

I find VSCode deeply unfriendly to my preferred method of editing code, and I imagine VSCode users find vim, kakoune, and emacs similarly unfriendly to their preferred method of editing code. Nobody is wrong in their findings -- what one finds unfriendly is objectively true to them.

But to say that I find VSCode deeply unfriendly is it not the same as your implying that terminals preclude "better" features and user friendliness. I'm simply recognizing preference, while what what you're saying seems to discount my (and that of many others) preference.

[edited for grammar and clarity]

I just skimmed the release blog post for Copilot Chat, and I don't see why it can't be implemented in a terminal based editor. Copilot itself was.

I've been using the vim vscode plugin in vscode-nightly with Copilot Chat for a few weeks. I'm far from a vim expert, but I think you don't understand the point of vim, which is perhaps best understood as a language for text manipulation. Also, I have not found the chat feature of Copilot to be particularly useful.

We? Speak for yourself

> I think terminals had a time and place

This is far beyond just an opinion about text editors. The terminal isn't going anywhere. It's the fallback, or sometimes the only, interactive mode available. Many developers use both vscode and vim on a daily basis, including myself. I see them as the best editors in their respective environments.

I like this kind of thinking: "Use the best tool for the job."

Reply on news.ycombinator.com