1. 63
  1. 11

    This article is a very nice read. I will be using it as an answer to the many people asking me why kak?

    I have switched almost a year ago and I cannot imagine myself going back to any other editors I have used before.

    1. 12

      And I will steal this paragraph, closest to my heart:

      If that doesn’t sound anything special, it means that it makes sense. Unfortunately, the field of text editors on UNIX systems has over the years turned into an archipelago, in which every editor aims at being an island. Job management, shell, terminal emulation, window multiplexing… Text editors have turned into closed ecosystems (or Integrated Development Environments) that provide many (sometimes cardboard-looking) features unrelated to editing, which new comers have to buy into, or be left out in the cold.

      1. 6

        Then why does Kakoune have a diff algorithm and a json parser among other things? In terms of code, it also uses a few data types/algorithms that standard c++ already provides.

        1. 11

          Then why does Kakoune have a diff algorithm and a json parser among other things? In terms of code, it also uses a few data types/algorithms that standard c++ already provides.

          There’s nothing unusual about the Kakoune project having their own data structures; it’s common for C++ projects to contain functionality that’s also in the standard library.
          I would say that this reflects more on the language then on the Kakoune project.

          1. 10

            There are various places where the internal diff algorithm is used, such as in the terminal output code (on the builtin-terminal-ui branch that replaces ncurses with a custom backend), when we reload a buffer or pipe part of a buffer through an external filter, the diff algorithm allows Kakoune to know what actually changed.

            Kakoune replaces some of the standard library utilities with its own for various reasons, HashMap is used instead of std::unordered_map to provide slightly different semantics (iteration order matches insertion order for example) and better performance (HashMap uses open addressing), RefPtr is used instead of shared_ptr because we use an intrusive ref count and we share the implementation with SafePtr (a pointer type that makes an object assert at destruction if any pointers to it remain alive).

            1. 1

              I think you are mixing two concepts, but I can understand you wrong.

          2. 6

            In Dutch, kak is slang for poop / shit. So I find your statement funny, why kak.

            1. 3

              Well, it is usual abbreviation of the program. My bad, as it is very similar in Czech (and some other Slavic langs). So better, Why Kakoune?

            2. 5


              Are you aware of the article (written by the creator of the project himself) titled “Why Kakoune?”, though? I didn’t expect that my article could be seen as an argument for the editor, it’s an interesting angle.

              1. 1

                I was not aware of it, thanks for sharing. Even if it is much more “why”, it is also much longer :-). And programmers love to steal in my experience :-).

            3. 6

              I really like the concept of Kakoune, tried it a couple of times and inverting the movement to action order is a great UX improvement. But unfortunately my muscle memory in vi is keeping me there, the differences is simply slowing me down too much. I would however love to see someone to “steal” Kakoune style editing in a vim extension, visual mode is the closest we have, which I do use quite a bit but it’s not quite the same.

              1. 7

                I might misunderstand you, but if muscle memory is what’s keeping you in vi, wouldn’t it also keep you from using such an extension?

                1. 1

                  The upside is that such an extension could be used on an opt in basis, e.g. by toggling it via a :ToggleKak or as an additional mode which can be entered from normal mode. This would allow me to instantly switch back to normal vi-mode thus making me able to get used to it gradually.

                  Additionally I was thinking an extension that keep more original vim movements instead of keeping some and changing others. Word is the same in kak but for instance foregoing g and GG for instance is a massive hassle, I don’t recall on top of my head what more was missing but there was quite a few changes. These changes probably makes sense if you start from a blank slate and thus makes sense for a new editor but as an extension to vi/m I’d rather see adherence to the old learned movement words.

                  Edit: Some things that I notice missing/changed at once when starting kak again and just trying to navigate a little bit in the project I’m working on right now:

                  • Folding, zc/zo
                  • Set line numbers, :set nu
                  • Go to line, :n where n is line number
                  • gcc/cs are popular plugins for comment and change surrounding, these are popular enough to be ported to vi-mode in other editors like vscode.
                  • At this point I’m going back to vi because it’s unfortunately slowing me down to much to get real work done.

                  Now I still love what kak is doing and if I weren’t already a vim user a lot of the things probably make a lot more sense.

                  1. 5

                    I found that the bindings that got changed from Vim was mostly an improvement in consistency, whereas original Vim bindings are constrained by their legacy. For instance in Kakoune shifted version of keys “extend” your current selection rather than move it. Thus, G is just g (which enters “goto” mode that includes g for buffer begin, j for buffer end etc.) that extends the selection rather than moving it, which is why you need to use gj instead of G to go to the buffer end.

                    Other than folding (which is not currently possible) your other missing features are actually available right now, so if you decide to give it a go again here are some pointers:

                    Set line numbers, :set nu

                    This is available as a highlighter, documented in :doc highlighters and the wiki page

                    Go to line, :n where n is line number

                    This is available with <n>g, from :doc keys

                    gcc/cs are popular plugins for comment and change surrounding, these are popular enough to be ported to vi-mode in other editors like vscode.

                    This is built-in with :comment-line and :comment-block commands, but not mapped to a key by default

                    I can’t blame someone much for not being able to discover some features – while in-editor help with the clippy and reference documentation with :doc is pretty great, it doesn’t have a good “user manual” like Vim that the user can discover features through. The wiki also helps but is not very well organized. TRAMPOLINE is a decent vimtutor replacement, but hard to find unless you know it exists.

                    1. 1

                      Thanks, that’s hugely helpful. Will for sure try out trampoline next time I give it a spin, I do love vimtutor.

                2. 3

                  Similarly for me, kak just simply isn’t available as ubiquitously as vi(m). I fear relearning the muscle memory would be a detriment in the long run as I would still likely need to switch back to vi(m) fairly frequently

                  1. 2

                    What might be left out about how common place vi(m) is the fact that there are vi(m) modes for A LOT of things, I’m talking editors like VSCode, IDE’s like JetBrains suite, Visual Studio, emacs evil, etc. but most importantly all major browsers (vimari/vimium/vimpinator/pentadactly/qtBrowser/w3m/etc), window managers (ultimate macOS for one), tmux, shells, scripting via s(ed), and more. Wherever these will diverge from kakoune there will be friction in daily usage.

                    Again this isn’t criticism to kakoune just a note on how ubiquitously available the vi(m) keybinding set really is.

                    Additionally to that I’ve worked with industrial control systems often being quite literary air gapped (not uncommonly located in rural places without internet connection) running some flavour of BSD/Linux, vi is pretty much always available for some quick adhoc configuration at a customer site, anything else, not so much.

                    1. 2

                      Yeah, this is also a factor for me, though less so as I have never been happy with a vim plugin/emulation layer.

                      1. 3

                        The one in VSCode is surprisingly good if you bind it to a neovim backend. Onivim is also interseting but more expimental.

                        1. 1

                          Have any sources on the neovim backend? I use neovim as my daily editor and was unimpressed by VSCodes vim plugin about ~1 year ago, but using neovim as a backend might address my concerns.

                          I’ve tried OniVim2, as I purchased a license way back when it was fairly cheap. Their current builds seem very promising.

                    2. 2

                      What distro are you using that doesn’t have a Kakoune package available? About a dozen are supported, it’s surprising to hear that the editor isn’t widely available.

                      1. 5

                        What distro are you using that doesn’t have a Kakoune package available?

                        Telecom-deployed clusters of RHEL VM’s.

                        1. 1

                          Can you not use this RHEL package?

                          1. 1

                            First, no el7 build, second, getting it there would be problematic at best (in terms of file copying).

                        2. 2

                          Alpine Linux. I also occasionally deal with embedded ‘distros’ that don’t have a package manager .

                          1. 4

                            I can see a package for Alpine, I’ve installed it myself in Docker containers.

                            In any case, it’s true that muscle memory is a big obstacle when trying to use one or the other. But when you switch over to Kakoune, it’s harder in my experience to go back to Vi bindings (for example when there’s absolutely nothing else installed on a random system).

                            1. 1

                              When I use vim nowadays (and I install kakoune anywhere I need to edit anything), I am staying only with the very limited set of commads.

                              1. 1

                                The Alpine package is on testing/edge, which isn’t considered stable. I already intentionally stick to stock vi(m) configurations as much as possible to alleviate muscle memory issues, switching seems like a step backwards to me despite the overall UI/UX language being better.

                      2. 4

                        What you could steal from the Kakoune code editor right now, and get away with it

                        The ASCII Clippy.

                        1. 2

                          And Dilbert!

                        2. 3

                          @lenormf could you please fix the github links in the article to make them permalinks, instead of pointing to the master branch? You can press y key on most pages on github, to make github replace master in the URL to a proper commit hash - that way you can have links that won’t bit-rot in a few weeks/months.

                          1. 1

                            Thanks for the feedback, that’s helpful. I’ve updated the links to have them point to code from the latest release (v2020.09.01).

                          2. 3

                            This is very persuasive. I wonder about an evil style emulation layer in Emacs following the same philosophy?

                            1. 5

                              There is kakoune.el but it doesn’t exactly “feel right”.

                              1. 3


                                If you want to use Vim, use Vim. If you want to use Emacs, use Emacs. If you want to use Kakoune, use Kakoune, If you want to use Microsoft Visual Studio 2020 Deluxe Enterprise Edition… and so on.

                                Just stop trying to mimic one software in another software, because it always be inferior and then such set of extensions might also make the target software behave poorly due to not ideal integration and not full Vim coverage (most of the time this is not even a proper Vi coverage). That’s understandable, because software with 100% Vim compatibility would be essentialy Vim. Or Neovim, for that matter. It’s not surprising there are no “Emacs modes” for other editors (even when there are, these are mostly readline-like keylayouts).

                                Just use (neo)Vi(m) or Kakoune or anything else, don’t hurt yourself with mixing, as you wouldn’t do the same with drinks :)

                                1. 14

                                  This misses the point — I don’t want a reimplementation of the Kakoune editor; I want access to its editing language. That is what evil provides for vim – it’s not vim, it’s a way to use vims philosophy in an Emacs environment. I want the rest of Emacs but with this more interesting approach to structured editing.

                              2. 2

                                I’ve been tempted to try kakoune for a while and this pushed me to install it and give it a quick try.

                                I’m already impressed. Very smooth feeling editing with some subtle feedback as I’m editing which feels useful and intuitive. I don’t know if it’s supposed to happen but I do like seeing what I’ve added this ‘edit’ and the search highlighting is lovely.

                                The clippy thing guiding is actually great. As a vi keys person I’m already able to do stuff and not get stuck - just knowing the basic idea that I need action then target (not sure those are the correct terms) rather than vice versa.

                                There is a kakoune editing plugin for VS Code so I’m tempted to try learning it now!

                                1. 2

                                  How kakoune pushes everything (any logic) into external programs is ehhh.. well, not always good.. let’s just say it’s annoying that you have to use the shell to have some logic in modelines. That’s a lot of fork/exec for something that’s refreshed all the time.

                                  1. 11

                                    Have you noticed a pragmatic slowdown? Awhile ago I wrote a plugin that shells out to awk (so two forks, one to sh, then to awk) to do rainbow paren highlighting*, and it runs on the contents of the screen every time the cursor moves and it is plenty fast enough. A frame on your screen is 16ms, it seems unlikely that a few forks are going to meaningfully slow down the experience. It also means I don’t have to learn a whole new language to make editor plugins (which, let’s face it, I just wouldn’t), which is great, I don’t have to have faith in the vimscript/elisp Illuminati to solve my specific problems, I can use anything in the Unix toolbox.

                                    Https://GitHub.com/bodhizafa/kak-rainbow if anyone is curious.

                                    1. 1

                                      No, but I have noticed tens and even hundreds of zombie shell/awk/etc processes in htop when editing text under super heavy system load (running massive builds), and occasionally never-ending “waiting for shell process to exit (1s)” under the same situation too.

                                      Also, it’s not the practical side that’s important to me, it’s just the dirty feeling that I’m burning CPU cycles on execing processes just for conditional expressions!

                                      1. 1

                                        In olde Unix, [ was an executable. It is the way 🤷