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

https://kakoune.org/why-kakoune/why-kakoune.html

by r3trohack3r • 3 years ago

179 89 3 years ago

kakoune.org

zokier• 3 years ago

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

jeltz• 3 years ago

What does Helix do that Kakoune doesn't?

lwhsiao• 3 years ago

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.

tester4572• 3 years ago

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

cosmojg• 3 years ago

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

unshavedyak• 3 years ago

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.

eviks• 3 years ago

Works on Windows

dang3• 3 years ago

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)

aidenn0• 3 years ago

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.

extr2• 3 years ago

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.

lytedev• 3 years ago

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!

wkdneidbwf• 3 years ago

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.

behnamoh• 3 years ago

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.

imbnwa2• 3 years ago

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.

tester4572• 3 years ago

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

steve_taylor• 3 years ago

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

acaloiar• 3 years ago

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]

davidatbu2• 3 years ago

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.

sethrin• 3 years ago

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.

triyambakam• 3 years ago

We? Speak for yourself

sublinear• 3 years ago

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.

throwaway2037• 3 years ago

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

imbnwa2• 3 years ago

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

Conscat3• 3 years ago

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.

bee_rider3• 3 years ago

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.

Y_Y• 3 years ago

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.

zamalek• 3 years ago

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.

bee_rider3• 3 years ago

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

rgoulter• 3 years ago

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.

chongli3• 3 years ago

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!

skribanto• 3 years ago

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

chongli3• 3 years ago

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

mananaysiempre2• 3 years ago

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?

chongli3• 3 years ago

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.

adrusi• 3 years ago

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.

brigandish• 3 years ago

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

shangxiao• 3 years ago

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

shhsshs• 3 years ago

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

jzm2k• 3 years ago

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

dang3• 3 years ago

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)

pizzalife2• 3 years ago

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

vivty• 3 years ago

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

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

pizzalife2• 3 years ago

Thanks!

ufo• 3 years ago

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.

galkk3• 3 years ago

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.

ambicapter• 3 years ago

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.

celeritascelery• 3 years ago

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

davidatbu2• 3 years ago

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

nequo• 3 years ago

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

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

3oH2y869• 3 years ago

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

cwp• 3 years ago

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.

girishso• 3 years ago

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

Kinrany• 3 years ago

What's Quicksilver?

jacknews2• 3 years ago

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

galkk3• 3 years ago

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.

lenkite• 3 years ago

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.

srijan4• 3 years ago

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.

lumb63• 3 years ago

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.

BaculumMeumEst• 3 years ago

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.

ltr_• 3 years ago

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.

Conscat3• 3 years ago

Actually yes. Its named Krabby

johnd15sp34• 3 years ago

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

hemogloben• 3 years ago

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

29athrowaway• 3 years ago

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.

oscribinn• 3 years ago

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

offices2• 3 years ago

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.

sebsebmc• 3 years ago

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

ctenb• 3 years ago

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

dang3• 3 years ago

Related ongoing thread:

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

tines• 3 years ago

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

Conscat3• 3 years ago

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

timetraveller26• 3 years ago

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

kmoser• 3 years ago

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

peepee1982• 3 years ago

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.

offices2• 3 years ago

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

usrbinbash• 3 years ago

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.

vbh21• 3 years ago

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.

throwaway71271• 3 years ago

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.

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

Related Stories