Hacker News new | past | comments | ask | show | jobs | submit login
Kakoune Code Editor (kakoune.org)
304 points by michaelsbradley on Jan 18, 2022 | hide | past | favorite | 170 comments



Past related threads:

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)


Does anyone use this daily? this gets posted a few times a year to HN but tbh it looks like someone just re-invented vi. Which seems kindof like creating a new religion. It can be done, but even the best televangelist isn't going to hold a candle to the spread of the catholic church.


I've gone for several week long stretches of using it but never fully converted. What winds up happening is that I get to a point in a project where I really need to focus on the code and not the editor, switch back to vim, and don't get around to switching back for another few months. The editing model is better than Vim's and if I didn't have 20 years of vim muscle memory I probably would have switched over by now.


I disagree that the editing model is better than vim. It’s fancier and makes for flashier demos but I don’t think it’s better. For one thing, it places the emphasis on editing in the large. That is, its default operating mode is to leave multiple cursors all over the buffer when you’re trying to jump around your file. You have to build a habit of pressing an extra key to dismiss the multiple cursors so you don’t inadvertently start inserting text in multiple places without realizing it. This is the wrong approach!

Vim puts primary emphasis on quickly getting around and making small edits one at a time. Editing in the large can be accomplished easily with the substitute ex command or search and repeat (via n and .) or macros recorded with q. For any programmer, the vast majority of their time is going to be spent editing in one place at a time. When they need to do something bigger, vim has them covered. If they’re finding they need to do some more sophisticated refactoring they probably want an IDE (or at least an LSP plug-in for vim of which there are many).


> That is, its default operating mode is to leave multiple cursors all over the buffer when you’re trying to jump around your file.

That's not true, motion commands don't create new selections. Search will create a new selection only if you explicitly ask for that by pressing shift N.


You can do the Vim approach just fine, and I usually do. I write prose in kak for goodness' sake, I don't usually have multiple cursors for that. The only time I accidentally get extra selections, besides old muscle memory triggering that feature in search with shift-N, is when I accidentally click in the terminal, which was going to mess me up with any editor.

But occasionally it's very nice to actually have that multiple selection feature. For instance, suppose you have a search and replace that you only want to do on certain instances of your search, in a context dependent way. You could just use n and . repeatedly. However, I find it nicer to examine each selection, drop the inappropriate ones individually, recheck my work, then do all the edits at once. This also eliminates (granted, by defining it away) the problem of changing your mind halfway through the search process about what change you want to make. When you change your mind, your cursor is either still live in all the places, or you're done, in which case at least there's only one thing to search for again, not the half that were changed and the half you hadn't reached yet.


> is when I accidentally click in the terminal, which was going to mess me up with any editor.

Well, most terminal editors don’t capture the mouse at all — this is what I personally prefer (let the terminal emulator handle it) and as a bonus it fixes this problem.


When I last looked at Kakoune, it struck me as “Vim with training wheels,” in the best sense of the term. In other words, it has (all of?) vim’s keyboard commands, but with more visual feedback to show what they are doing live. I envisioned myself learning with Kakoune and eventually migrating to vim once they became ingrained. Or, at the very least, becoming proficient in vim so that I could use it more confidently when needed.

Has that been anyone’s experience?


I don't believe that'd help.

Editing in Kakoune encourages and enforces a different editing style (one based on visual selection).

You'd have to still learn Vim.

Personally, I played https://vim-adventures.com/ to get a basic grip on Vim, later I kept a cheat sheet handy, and yet later I just looked up commands and features as necessary.

I recommend disabling the arrow keys in your vim config and to just use it.


I've been using Kakoune as my daily driver for almost a year. The thing that made me fall in love was the simplicity, both in daily usage and in extensibility.

The biggest "oh wow" moment for me was how easy it was to create a color scheme. In Vim, creating your own color scheme is potentially a huge ordeal, with many edge cases. For example, vim-one's color scheme file is over 800 lines long.

By contrast, I created a fully functional Kakoune color scheme in only 84 lines, 60 lines if I remove extraneous spacing and comments. There is no conditional logic, no legacy support, just one set of standard "faces" that work everywhere. All languages use the same standard set of faces to do their syntax highlighting. The difference that makes is astounding.

This is but one example of Kakoune's orthogonality and simplicity of design. Coming from Vim, which is chock full of legacy code and an inconsistent mess of configuration, it's a breath of fresh air.


I would have thought that creating/adapting a colour scheme is a onetime activity when you start using the editor for your language. Do you update the colour scheme regularly?


I used color schemes as an example, perhaps it was a bad one. I don't update it regularly, no.

As others have said, the appeal of Kak is orthogonality and accessibility. The keybindings are sensibly organized, there is exhaustive autocomplete and on screen documentation, and the configuration language is simple. It is ridiculously easy to write plugins for, because you can use shell scripting, or create a program in any language you want and invoke it from a shell block. Kakoune's LSP plugin is written in Rust and communicates with Kak via the shell.


Sorry if it looks like I was being flippant. I wasn't. I had some colleagues in the past that did adjust their colour scheme almost monthly. I think it was when syntax highlight first came onto the scene back in the mid 90s.


Oh you're fine! I didn't think you were being flippant. I've been using One Darker (One Dark with a darker background) for two years and don't have any plans to change anytime soon. Here's the source for the theme if you're interested. It has gotten a little bit more complex than I described in my post, due to supporting various plugins, but it's still pretty easy to understand.

https://github.com/raiguard/one.kak/blob/main/colors/one-dar...


I think he gave that as an illustrative point about the simplicity of Kakoune, rather than saying this specific example is why he uses it.


I am using it daily, as my sole editor, for a little more than a year now. Before that I used Neovim. Most important reasons for the switch are:

* Leaves window management to the window manager, so it works much better with a tiling wm. I wish all applications did this.

* Selecting first and then specifying an action works way better than the other way around, as it is done in the Vim family.

Edit: regarding the comments and Vim's visual mode, you are right. I like to change my second bullet to "Does not have too many modes, like the Vim family."


> * Selecting first and then specifying an action works way better than the other way around, as it is done in the Vim family.

There is visual mode in vim too you know. That's for doing exactly what you describe. I use that when I'm unsure about the movement I need for an action.


That's exactly what I used to say before I tried kak. I had been using vim for about 6 years and thought it sounded like vim with multi select and wasn't impressed.

The reality is, you change the way you think about editing. It took about a week away from vim but eventually I could see the selections in realtime. Not as a gimmick like with multicursor vim, but as the basis of everything. I have been using it exclusively for 2 years and haven't looked back once. Single-cursor editing is about the same speed, but selection oriented editing blows vim out of the water with anything with 2 or more edits.

It's like if a notepad user said "what's the point of vim? I can just use a mouse and arrow keys??" Vim changes the way you see things - you see a space separated word so you use W or a line with whitespace at the beginning so you use I. It's hard to explain other than you change your understanding of editing.

Edit: that gimmick comment might annoy some people. I used to use it and love it. But the reality is, it was just an add-on to an already-grest editor. After my plugin phase of vim, I realised it didn't really add much at all. So 'gimmick' is probably too harsh


Visual mode only allows for a single selection, though


You don't need multi-cursor selection in vim.

Vim has all the tools necessary to achieve the same end result with the same convenience. [0]

Just thinking about what crazy things I've done with macros that multi-cursor would be incapable of handling makes me chuckle.

vim doesn't need the fancy features of other editors (except for maybe LSP and tree-sitter for a more IDE-like experience).

The core problem is that you don't grok vi [1] which is fine, not everyone has time and passion for that. But please don't think for a moment that vim is inferior just because it doesn't blindly copy other editors features.

[0] https://engagor.github.io/blog/2018/02/21/why-vim-doesnt-nee... [1] https://stackoverflow.com/a/1220118


Judging by https://github.com/mawww/golf kakoune is capable of completing the majority of the same editing tasks as vim in a very similar amount of keystrokes. The main advantage of multiple selections is that you can see which text you will operate on ahead of time, rather than having to first select which operation you want (delete/yank/change/etc) and then which text it will affect. I think pointing out that vim's selections aren't as capable as kakoune's is a fair response, and saying that you can accomplish similar things without selections is a bit of a deflection.


80 Better 18 Same 35 Worse

Golfing is not the best representation of day to day text editing, but I must say that optimal Kakoune solutions are usually pretty close to normal workflow.


> vim doesn't need the fancy features of other editors (except for maybe LSP and tree-sitter for a more IDE-like experience).

Both of which neovim has.

Agree with your premise, though: (n)vim does not need multi-cursor selection, for the reasons have given.


Don't get me wrong, I'm a nvim + LSP + treesitter user. :)


Vim allows me the exact same thing using visual mode. even better, I can still use the powerful move commands in visual mode to control what is selected, before triggering an action on the selection.


I tried to use it enough to see if I could switch to it from (neo)vim. I liked a lot of the ideas in it, and in some ways I liked it more than vim, but it was missing some functionality that I just couldn't live without. Some things could be solved by plugins that just didn't exist yet, but others, I couldn't even see a way a plugin could be implemented. In particular, there isn't any way to get a diff mode comparable to vim's.

I also don't like that it always unconditionally writes a newline at the end of files. I understand the reasoning for it, but it makes it much more difficult to use as an editor for transformed binary files (gzip, hex editor, encrypted files, etc.) or avoid adding extra whitespace to git diffs when I modify files.


I don't understand the new line thing at the end. I haven't used a utility or app in -decades- that cared about whether you have a blank final line.


There's a few reasons I can think of (some superficial, some significant):

- Github and git will highlight a missing newline in a diff by default.

- POSIX defines a line as having a newline at the end, so if you don't have a terminating new line you may have one fewer lines than you think you have [1]

- If you ever want to append to a text file/source file programmatically with something like echo "something at the end" >> yourfile.txt then you'll be grateful you had the habit of ending everything with a newline.

- If you use a shell that doesn't automatically add one when you do cat filename you'll end up with your prompt sitting awkwardly at the end of the file.

vim, iirc, defaults to automatically adding a newline to any file without you explicitly asking for it, unless you do set noeol and set binary or, in versions newer than 7.4, set nofixendofline

[1] https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1...


> vim, iirc, defaults to automatically adding a newline to any file without you explicitly asking for it, unless you do set noeol and set binary or, in versions newer than 7.4, set nofixendofline

which, IMO, is the right way to do it. In kakoune however, it isn't just the default, there is no way to turn it off.


I just ran into an issue with that recently. The Pandas library for Python doesn't consume the last line of a CSV unless it's followed by a new line. I would say I couldn't believe that it actually made inject that newline if it wasn't in the input, but Pandas has enough other oddities that it was pretty easy to believe.


`cat`, for instance, definitely cares.


Do you ever do wc? It cares:

  > echo hello > hello
  > echo -n hello > hellon
  > wc hello hellon
         1       1       6 hello
         0       1       5 hellon
         1       2      11 total


Have you used cat recently? [Edit: scrolled down, looks like several other people already beat me to it. Whoops.]


I think it used to be a requirement (technically) for C and C++, though probably not much any more in practice.


The GreenHills C++ compiler does. It's a niche product, admitted.


Literally cat


breaks some crontabs.


I've used it daily for ~6 months now. Before that I had used Vim for close to 8 years and tried many different editors during that time but I always went back to using it. I feel Kakoune truly is an improvement over Vim and I highly suggest you try it if you like modal editing.


At Symflower we do, one of us has it as its main editor and it looks extremely productive. As a former VIM hardcore user i enjoy the pair programming sessions. I guess these sessions must feel the same way when a non-VIM user watches a VIM hardcore user.

We even have an extension for Symflower https://github.com/symflower/symflower-kakoune that is how much we appreciate Kakoune.


I use it daily for many years, being a user of vim for 20 years or so. I could not come back to vim now, I find the kakoune way more efficient.

I find two annoying things :

- U need to make a lot of tuning to make it usable because there is now tab management, no clipboard, etc..

- U need always the last version of C++ compiler to make it compile. This is annoying on professional VMs that are way behind the current version of gcc.

I would suggest the community to make better documentation for plugin development which can be very hard to learn


I had the same problem building Kakoune on more elderly systems, and settled for building a static binary on my own machine that I could then run on shell accounts on other people's boxes if the toolchain isn't new enough to build in situ.

kak locates its runtime library relative to the binary path, so it works fine in ~/bin & ~/lib or ~/.local/bin & ~/.local/lib even if your home directory is different on different machines.


>This is annoying on professional VMs that are way behind the current version of gcc.

Get binary PKGSRC packages from Joyent and set PATH accordinly.

https://pkgsrc.joyent.com/install-on-linux/

It's for RHEL and clones but it should work on any parallel distro or more recent.


shameless plug for my tab manager plugin: https://github.com/enricozb/tabs.kak disclaimer: I'm in the process of a decently sized refactor so the configuration instructions will soon be changed/outdated.


Several of my coworkers use it instead of Vim. It seems pretty nice, and I've been tempted to try jumping ship now too.


I used Vim for ~7 years, fully switched over to Kakoune a few years ago. My primary reasons are:

1. always selection-first focused

2. multi-cursor support combined with #1 is really intuitive

That's about it really. I have it set up primarily with User Modes, to avoid modifier keys as i don't like reaching for modifiers, and i'm pretty happy.


I've been using it as daily driver for 3+ years. I switched from Spacemacs. Focus on selections, visual feedback and simple integration with other Unix tools are main differentiating features in comparison to vi family of editors.


I have used kakoune almost exclusively for two years. Prior to that I used vim for 16 years, emacs for 10 years before that. For me kakoune started as vim visual mode done right, but I have come to love the editor because it has a small orthogonal command interface that provides all the power I had with vim, but with lower cognitive burden.

Kakoune is a fantastic tool of rare quality. I find it a joy to use.


I tried it for a short time, but given the ubiquitousness of vi/vim, I just couldn't get myself to commit. I want to keep my muscle memory intact for when I have to ssh into a remote computer somewhere. Which, I guess what I'm saying is, it looks like I'll be attending mass this Sunday.


I've been using it for the better part of three years after using Vim for many years.

What I like about it that it is intuitive. Selections make sense. The visual feedback is great too. I've configured nearly nothing, the out of the box experience is great.

I'm never switching back to Vim.


kak is my daily driver. About the only customization I do for it is the integration of fzf for file picking-- althought its window management with kitty seems to be broken, I have to run it inside tmux for this to work. Recently I more often than not use broot as the launcher for kak instead of directing kak to open files from inside kak.

Multiple selections with the visual preview before action was the key feature for me-- it is a nice affordance compared to having to mentally model what an operation would do with a vim movement.


That seems like a weird analogy. There are fabolously rich and successful American megachurch pastors (or whatever they are) that probably have no connections to the Catholic Church.


It replaced sublime text for me for scripting languages like PHP, bash and stuff. I still prefer VSCode for js/ts and native IDEs for compiled languages.

I love it.


TWM was reinvented into FVWM and the later one was much faster, it used far less resources and functionality wise it ran circles over TWM.


I agree with this one, it's just like creating a new branch kind of lifestyle or something like that.


There is also Helix, inspired by both Vim and Kakoune, with built-in LSP support. I'm having a great time with it.

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


Hey thanks! That's good to hear :)


Assuming you're related to Helix, how does it relate to Kakoune on the selection-first approach? That's one of my favorite features of Kakoune, curious how Helix handles that if inspired by Kakoune?


I just went through the tutorial. It's not bad, though there doesn't appear to be much documentation (there's not even a built-in :help command, and :tutor is rather minimal).

What do you like about it compared to Kakoune?


0.6


Check out helix [0] for a kakoune inspired editor with some nice modern features included by default.

[0]: https://helix-editor.com/


Have been using this instead of vim for a month now.

It's incredible. No messing with plugins and archaic config files. All works out of the box, including LSP integration. Highly customizable still. Extremely fast, too.

I love "space-k" (Show docs for item under cursor).

The one thing I'm still struggling with is the kakoune-like movements. Maybe I'm doing something wrong, but they do feel inferior to vim's.


I agree it's nice, but Helix's default LSP for Python is unusably slow, having used pyright with Vim/Emacs/VS Code. I tried setting up the pyright language server to work with Helix, but could not get it to work. It will be much more usable once there's better documentation.


what kind of motions are you missing? I prefer helix to default vim, but miss the power of the amazing lightspeed.nvim plugin.


There's been some prototyping on easymotion type jumps: https://github.com/helix-editor/helix/pull/1162


In Vim you can also hit Shift-k to open docs (I usually use it for manual pages).


In this case, space k will open a popup with docs/definitions provided by the language server.


Very intrigued, waiting for the wasm-plugins though.

There are a few plugins I cannot work without. It's nice they have tree-sitter and lsp out of the box, but I can't live with things like hop[0]

[0] https://github.com/phaazon/hop.nvim


I got curious about this and found https://github.com/danr/kakoune-easymotion which I'm going to give a try.

I haven't tried helix in a while, sometimes they have chosen not-quite default-kakoune like bindings which trips me up for certain kinds of selections.


It's a bit surprising how many easymotion style plugins (n)vim ecosystem has. I discover a new one every other week or so.


Helix is my daily driver and it's got such nice defaults I haven't even bothered configuring it.

For modern code editing it's just faster. Everything's built in natively.


I made two changes: switched my theme to everforest-dark and reduced scroll-lines from 3 to 1.

I was very happy to see that second option as it still hasn’t been implemented in neovim [0].

[0]: https://github.com/neovim/neovim/pull/12355


I use Kakoune very extensively. I've tried out Helix a bit though. While I'm adequately informed to make an assessment about Kakoune, my opinion about Helix is more impressionistic.

My overall assessment is that Helix has the potential to run away with the Kakoune interested crowd! For a new editor Helix looks shockingly polished!

Here is what I like:

- Tree sitter is integrated into Helix. Kakoune use a lot of regexes for syntax highlighting (except when the syntax highlighting can be done by the LSP). I really like that

- LSP is built into Helix so you don't need to worry about adding extra plugins. It just works! (Worth mentioning: Kakoune has amazing LSP integration via the separate kak-lsp plugin though)

- Helix is built in Rust. Kakoune is built in C++. I've encountered the occasional segfault in Kakoune and I would guess that these would be rarer in Helix simply because Rust makes it easy to write "safer" code by default

I find Kakoune as more minimalist and consistent in its editing philosophy. Helix AFAIK does not have a good plugin story yet. OTOH it is almost trivial to write a plugin in Kakoune.

Kakoune's pure-editing features (multiple cursors, selections and other primitives) seem richer and deeper. Helix has a wider selection of features "out of the box". As Kakoune has been around for a while it feels more mature. Helix is designed to be an "editor for all" and tries to be a bit like spacemacs with the spacebar as an important key. (BTW Kakoune has relegated the large spacebar key to a relatively minor functionality which is a pity).

Helix feels a bit more responsive and snappy than Kakoune on my machine. (But both are very fast). That could be because I was comparing vanilla Helix with Kakoune+plugins. However, long term, because Kakoune likes shelling out frequently, that might be a bottleneck on how responsive Kakoune will always ultimately be.

Helix seems to have a very fast pace of development. Kakoune moves much more slowly and ponderously. Kakoune's creator is quite hesitant about adding new features possibly in a desire to keep the core editor small and consistent. Kakoune also tends to be a bit opinionated about accepting features in general in its code-base.

Coming to the innards of Helix & Kakoune you can see the differences in the philosophy of both editors. The Helix code base liberally uses many rust crates to build the editor. Apart from a recent C++ compiler and a posix system Kakoune has literally _no_ dependencies -- not even ncurses or a regex library! Basically, Kakoune likes to build everything in-house. This approach has its benefits and pitfalls which I'm not going to debate here.

While Kakoune has had a lot of community contributions over the years, Helix seems to have lot of community momentum behind it currently.


> Helix is built in Rust. Kakoune is built in C++. I've encountered the occasional segfault in Kakoune and I would guess that these would be rarer in Helix simply because Rust makes it easy to write "safer" code by default

No segfaults, but Helix is definitely somewhat buggy at the moment, especially on Windows. Panics make it relatively easy to debug though.


Kakoune is gimped by the fact that Mawww had children and cannot dedicate nearly as much time to the project as they had planned to. The idea was to have monthly releases, but that quickly fell by the wayside.

Helix is interesting, and built in LSP and Treesitter is really cool, but it feels like it's missing some of the core principles of orthogonality that Kakoune has. It has the potential to overtake Kakoune very quickly simply due to how active its community is.


How did you get Kakoune to segfault?


Kakoune is built in C++. So bugs will sometimes manifest as segfaults. You could be doing some normal editing, press a sequence of editing commands that might trigger some code that may subtly wrong. Sometime later, when C++ code tries to write to memory that it shouldn't have, you will segfault.

In that respect this is true for any C/C++ application. Kakoune keeps fixing these issues as they come up.


> tries to write to memory that it shouldn’t have

To elaborate what I mean here is maybe the program tried to write to an address not mapped to its address space etc. This happens due to bugs in the program e.g. not calculating the offset into an array properly and so forth. There are many ways to mess up when using C/C++!


You can segfault in rust, too:

  fn totally_safe() -> i32 {
    unsafe { *std::ptr::null() }
  }
This commonly happens if the person who wrote 'totally safe' thinks what they're doing is fine, and it actually isn't.


wow, I pulled up a C++ file in Helix just now -- never used it before -- and the LSP just worked out of the box. Amazing. Setting up LSP is usually quite a pain in editors like this.


I gave it a try but I couldn’t figure out how to disable the editor help popups or hide the line numbers. For all the sane defaults, I’d miss the configurability of Vim.

The code is well organized, and compile times are short, so at least it’s hackable.


I tried kakoune on the basis of a blog post I found here a while back, that described its better-thought out Vim-like command language. I was hooked almost immediately. Now I use it daily. So if you like Vi/Vim's text editing model but wish its language was more orthogonal and powerful, give Kakoune a shot.


I started using Kakoune a few of years ago, after a decade+ of Vim, and while the improved command language is nice, the parts of Kakoune I love are:

- dedication to quick feedback

- scriptability and plugins

By "quick feedback" I mean things like multiple selection support, so you can tweak and polish a complex search-and-replace and inspect each step of the process as it happens, instead of writing a complex regex, undoing, and starting again from scratch.

I also mean things like pervasive completion and tool-tips. When I type `:set` I don't just get tab-completion of option names, I get a browsable list of option names and a tooltip describing the syntax of the `:set` command. And once I pick an option, that option's docstring is added to the tooltip so I can see what values the option expects.

By "scriptability and plugins" I mean there's no special directory structure to make a plugin - just take the commands you'd type in the editor, stick them in a `.kak` file in `~/.config/kak/autoload` and you've got a plugin you can share with your friends. If you have a complex editing operation you want to script, you don't need to learn a whole different "long-form" syntax for each command, you can just say `execute-keys` and write out the keys you would press to do the thing. There's more ceremony and polish you can add if you want (like all the fancy completion built-in commands have) but the effort required to automate my tasks is damn near zero.


What did you find easier/more powerful about Kakoune than its equivalent in vim?


The multiline cursor is a great tool I didn't know I needed before I tried Kakoune. Also, the commands are more logical. Go to end of line with gl, select code from current place until the end of line with GL, go to the start of line with gh, go to the end of file with gj and to the top with gk, etc. It's more logical and the fact that you can use visual select by keeping shift down when moving is very nice.


What’s the big deal with multiline cursor over visual block mode?


I think multicursor is more flexible. I can visually select N lines and use regex to place the cursors and then modify the text in multiple places simultaneously. Kakoune also provides a multicursor similar to the visual block mode that Vim offers but I find myself using that only in very specific situations like "these 5 lines should all start with this keyword" or whatever.


imo, Multiline cursors are one of these features that look and feel cool, but are rarely, if ever, really useful.


That's shocking to me. Ctrl-D in visual studio code and alt-J in jetbrains are some of my most used key combinations. Even alt-click in visual studio code is sometimes extremely useful. It's like the ability to record and play back a macro multiple times, except you do it interactively and can see / fix / add things as you go.


I use it daily and find it immensely useful.


That's also what I thought as a Vim user before I had access to Kakoune's multiline editing. It changed my mind and might change yours too if you give it a chance


I used editors with multiline editing capabilities in the past.

There are only 2 usecases where it was of any value to me: If I have to write multiple lines in a similar fashion, or if I have to edit the same thing in a similar fashion in several places at once.

Both can be done much easier by using a regular expression.


I disagree. In the past I've used regex to do that and now that I have access to a multicursor, I won't be going back. I think with regex you don't get the same kind of visual feedback that you get from a multicursor which is why I (and many other Kakoune users as well) like it so much. If you're happier with regex and feel like you don't need multicursor, that's great.


In case it helps anyone, doing regex-based search/edit in vim was annoying until I found this plugin. https://github.com/haya14busa/incsearch.vim


Ditto. I rarely use multiple cursors in other editors, but I use them _constantly_ in Kakoune. I have been using it for multiple years. The composability of the command language is what makes it shine.


movement before command sounds nice, eg 'wd' to delete a word instead of 'dw'


I find it extremely subjective. "delete word" is much better than "word delete" imo.

Also `dw` sounds more logical if you think about user input speed\pauses. If I press `w` I want to move to the next word immediately. In case were `wd` deletes a word - there should be some lag, no?


Doing the motion first lets you visually confirm the range before invoking the command. You also have the opportunity to adjust the range if you didn't get it quite right.

Mnemonically the vim order works better for English but in practice I find the visual feedback from selection better for anything even moderately complex. An example would b `f` or `t` since I tend to hit the letter I was aiming for earlier than I was expecting.

> In case were `wd` deletes a word - there should be some lag, no?

There's no animation or forced latency. For a short motion that's predictable like `w`, you're typing the d before you actually check the result and it's just as fast as vim but in the opposite order.


> Doing the motion first lets you visually confirm the range before invoking the command. You also have the opportunity to adjust the range if you didn't get it quite right.

It should be noted here that Vim more or less works like this in visual mode. If you go "v <motion> <command>" instead of "<command> <motion>", you can visually confirm the range. I can see the argument that it should be the default, though I like the fact that <motion> alone in normal mode just moves you around without preparing for a command.


The same visual feedback exists in vim.

    vwww
selects the next 3 words visually. I can now press `d` to delete them.


I have never felt the need to visually confirm something as obvious as "delete 1 word".

On the other hand, you cannot do something like "delete 3 words" in kakoune. "3wd" just takes you to the third word and deletes that.

Deleting 3 words is definitely slower. And it's kind of infuriating...

What am I doing wrong?


Lowercase w resets (each) selection to end of selection, skips any whitespace, and selects to next word boundary, so www or 3w will select third word counting from cursor. Uppercase W extends selection over any whitespace and then to next word boundary, so WWW or 3W will select from cursor to third end of word. (Most other movements are also in lowercase resetting / uppercase extending pairs.) Thus with length-1 (that is, initial-state) selection you can do wwwd or 3wd to delete third word and preserve whitespace, wWWd or w2Wd to delete three words but preserve whitespace, WWWd or 3Wd to delete three words and any whitespace between cursor and start of first word.

That is, counts work, it’s the movements that are slightly different. See manual §3.4–6[1].

[1]: https://github.com/mawww/kakoune#34-movement


>There's no animation or forced latency. For a short motion that's predictable like `w`, you're typing the d before you actually check the result and it's just as fast as vim but in the opposite order.

Yeah, I just realised we are talking about normal mode basically...


> I find it extremely subjective. "delete word" is much better than "word delete" imo.

Yes, as single command typed in isolation whether dw is better or wd is better is a matter of personal subjective opinion.

But, where object-verb (wd approach) becomes objectively better is that it composes with subsequent editor commands in a way that verb-object (dw approach) does not.

Editing is all about performing operations on text. You can first make increasing complicated selections, review them as they are being built up and then decide what to do with them in the end with the object-verb paradigm.

All this is difficult to describe textually. Try to checkout some Kakoune editing on YouTube or do it yourself by looking at the TRAMPOLINE tutorial [1] and you might come around to the `wd` school of thought!

[1] https://github.com/mawww/kakoune/blob/master/contrib/TRAMPOL...


In my mind I read "wd" as "select word, delete selection" which matches well with the visual feedback Kakoune gives you.


> which matches well with the visual feedback Kakoune gives you.

Do you really need this feedback though? I can understand this when yanking, but if I'm going to delete the word... The whole action take much less that a second and then I proceed with my task.

Well, to each their own I guess


You're taking the example too literally. The point is that using the motion first gives opens the possibility of visually confirming what the action will be taken on. The usefulness of that improves when the motion is complex. But nothing forces you to confirm, so if you're confident it's right you can immediately follow the motion with the action. That loses you no time compared to Vim.


>when the motion is complex

>multiple cursors (from a different comment)

I agree that in this kind of case motion first may be a way to go. Basically it should look like `search && replace`. Without actually doing search && replace.


Exactly what @ziml77 said.

Even in the case of simple "wd", sometimes I have multiple cursors I am operating on at the same time (e.g. from complex regex or just through selecting multiple lines at once) so each cursor could point to fairly different things. Then, the visual feedback becomes very useful.


The benefits pile up quickly when you want to do something even slightly more complicated. Hit w a bunch of times until the selection looks right, rather than count words. Tweak either end of the selection to catch spaces or punctuation.

You can do all this in Vim, I'm sure, but it's less mental effort in kak, because to a much greater extent you can see the results of your actions before they happen. And it's no slower if you do happen to know exactly what you're doing, because it's almost the same keystrokes in different order.


Once you realise that it's, er, let's say, inspired by vim, you look at the logo and see that it's basically a clone of the vim logo/icon - the orange part of the K looks like the V in the vim icon, and the green lozenge background is almost exactly the same. Which makes it even stranger that they are trying to hide that - there is no mention of vi/vim on the site's landing page. Ok, I understand that they are wary that mentioning "vi(m)" could scare people away, but come on, they are going to find out anyway sooner or later and lose interest then, so what's the point?

Also, what happened to proudly mentioning your software is open source and all the "fork me on GitHub" ribbons/banners/whatever? They seem a bit shy on that too - which is all the more bizarre because most of the links in the top navigation actually go to GitHub, but none of them are labeled "source code".


Maybe not on the landing page, but there's a large button saying "Learn More about the Kakoune philosophy" that leads to this page [1] that mentions vim 5 times and vi 11 times, including:

"It first started as a reimplementation of Vim"

"A design goal of Kakoune is to beat vim at its own game, while providing a cleaner editing model"

"Up to now, I have used vi as an example for modal text editor, mostly because I expect most programmers have at least heard of it. However, I don’t believe vi and clones are the best modal text editor out there."

and so on.

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


AFAIK the creator got the inspiration from Vim, but I think the other statements about github, not mentioning vim, etc. Are just products of your imagination


That the landing page doesn't mention vi/vim or open source is definitely a fact. Of course the reason for not mentioning vim was a product of my imagination, but actually I just wanted to say that I think it's odd for them to avoid stating the almost-obvious...


> avoid stating the almost-obvious...

I feel it's in the nature of communication to avoid stating the obvious and only becomes problematic when what's obvious to the sender is not to the receiver.

Paradoxically while too much obviousness makes a statement banal, being the first to explicitly state what's obvious to everyone is extremely insightful... :)


Both the "Learn more about the Kakoune philosophy" and git repo prominently state it's inspired by vim. Why are you thinking they're hiding it just because it's not on the landing page?


I just clicked over and looked at the repo which answered my question. No big deal.


Note the existence of kakoune.el, an emacs emulation of Kakoune's core:

https://github.com/jmorag/kakoune.el

I have no idea how well it reproduces the experience - I'll probably be using vim on servers and emacs evil-mode locally until the day I die, so I haven't bothered to get into Kakoune, awesome though it seems.


Why would you even bother making Emacs look like Kakoune?

Funny how it seems a lot of Emacs developer time is spent a) making it look like / act like something else and b) making it do things unrelated to editing text.

There is no focus. It's good that it can do a lot but it doesn't do any of those things well (unless you want to learn some cryptic key combinations that make less sense than vim).

Meanwhile the rest of the world has moved on.


> Why would you even bother making Emacs look like Kakoune?

Because somebody wanted the Kakoune core editor behavior combined with the world of features emacs gives you.

> Funny how it seems a lot of Emacs developer time is spent a) making it look like / act like something else

Somebody found this useful. Would you have preferred that this person didn't do any of this at all?

> and b) making it do things unrelated to editing text.

Yes. Unlike vim and kakoune and others, emacs is much more than a text editor.

> There is no focus.

What focus? Somebody wanted to do this for themselves. There's no "emacs, inc" that sets the focus that all devs follow. This is how free software works.

> It's good that it can do a lot but it doesn't do any of those things well

I'm going to go out on a limb, and guess you aren't an emacs user? It does most of those things fantastically well.


> Somebody found this useful. Would you have preferred that this person didn't do any of this at all?

The usual conversation starters about emacs go "oh you have Spacemacs, you have EVil, you have plugin X, Y, Z, etc, etc"

Whereas with other editors the focus is on improving the core experience

Plugins are great, sure, but there seems to be an excessive focus on it and most plugins just don't give you the same experience.


You're clearly not involved in the development of emacs, and your perception of the "focus" is based on talking to newbies. Respectfully, go read emacs-devel to find out where the focus is.


go read emacs-devel to find out where the focus is.

If by focus you mean distilled yak shaving, then emacs-devel is the place to be. Emacs is going nowhere because elisp makes it too easy to work on the plugins relative to the C core which was showing its age 15 years ago.


The C core is getting a feature to compile elisp to native code in the forthcoming Emacs 28. I've yet to try it, but I understand it offers a significant speed boost.

It's certainly true that the core C codebase has some major parts that are aging poorly, but it's not true to say it's going nowhere.

(As one who has shaved plenty of yaks and occasionally reads emacs-devel, I'd say it's the place for distilled bikeshedding, not yak shaving.)


> ... but it's not true to say it's going nowhere.

I'm using the "native comp" (of elisp to native code) since it's available (years already now? Don't remember exactly but a long time). That, combined with a fast JSON parsing lib and LSP and Emacs is definitely not just the Emacs of 15 years ago.

Other things happened to the Emacs world too: ivy/avy/counsel (and maybe lispy and hydra) are stuff I couldn't live without anymore.


Just look around this thread for the issues people list with kakoune. I.e. hard to configure, window management, lack of IDE features, lightspeed/avy, localization, etc. All of them are trivially solved by using a kakoune layer on emacs instead.


Kakoune's [design doc](https://github.com/mawww/kakoune/blob/master/doc/design.asci...) stresses that Kakoune is a text editor, not an IDE. What does this really mean? Obviously, the main way people use text editors like this is to develop programs. So, given that Kakoune doesn't want to be an IDE, what features does/will it lack?


There is a Kakoune-inspired VSCode extension. [1]

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


I've used this extension -- its nice -- but it can never give you the full experience.

If you're new to Kakoune, I'd recommend just using the real Kakoune for a while and see if you like it. Once you truly understand the object/verb modal editing (vi is verb/object) + multiple cursors paradigm you might love it, as I did.


I've been using this over the past few months and so far, the only thing that really bothers me is that there's no UTF-8/Unicode category selectors support in their self-rolled regex engine, citing not wanting to ship a unicode character database to keep the editor small (only mentioned on IRC, sorry). This makes writing syntax highlighting extensions a pain/difficult to maintain[1].

---

[1] https://github.com/mawww/kakoune/issues/4411


I understand not wanting to ship large tables, but then why not ship the scripts to generate the tables from the publicly available source of truth?


Kakoune does not yet have an interactive tutorial, like vim's `vimtutor` -- its developer community has mixed feelings about the need to develop an analogue. In lieu of it, there exists a document called TRAMPOLINE that is meant to help new users get up to speed quickly. It is available here: https://github.com/mawww/kakoune/blob/master/contrib/TRAMPOL...


kakoune is more discoverable than vim.

You get an explanation of each command and its arguments, plus suggestions and completion, without the need for any plugin.

The basics of the vim tutorial still apply to kakoune.


> kakoune is more discoverable than vim.

Yes, this is one of its most underrated features.

Make sure you have to following line in your kakrc

```

set -add global autoinfo normal

```

This will give you an explanation on the various commands that you perform in the normal mode of the editor in a unobtrusive popup on your screen.

When you type commands e.g. `:w` you will get a popup again that explains the optional switches available when saving a file. In vi, you usually need to hunt down things in documentation. In kakoune, the documentation is displayed as you work in your usual workflow. This made things really easy for me.



Since Kakoune is a C++ codebase, they're standard language keywords, not macros.


When I tried Kakoune, it seemed like a really cool idea and implementation, but it didn't seem like their configuration language had basic functions for string manipulation, path testing, etc. So a common pattern with plugins etc. was to shell out to sed, awk, etc, which was a _huge_ turnoff. I now use Neovim, but if they have recently implemented that functionality, I'd be willing to give Kakoune another shot


Shelling out was a turnoff for me also initially but I've learn to embrace it. Kakoune tries not to re-invent the wheel. If sh/sed/awk/perl/other unix tools do the job well, might as well use them. That is the philosophy I think.

I like the fact that using Kakoune has improved my shell script skills like crazy. (Posix) shell scripting is just everywhere and is an important skill to have. Kakoune uses shell integration everywhere and I've come to appreciate the the pragmatism/elegance of the "kakscript as a glue language paradigm".


Sure POSIX shell scripting is a good skill to have, but I would hardly consider it good for a text editor to have that skillset be commonplace within their configuration language. Shelling out incurs a non-zero execution cost. For example with Bash, it is significantly slower execing out when using a builtin or parameter expansion will work just fine, especially with these types of quick text manipulation operations. And that's not even mentioning that you are literally starting up a new Bash process every time you want to do something semi-complicated in a Kakouine config. This doesn't just leave a bad taste in my mouth - it is also a giant waste of resources and causes initialization to be substantially slower compared to the alternative

It is also too easy to write poor shell scripts. It is too easy, even for experienced developers to sneak in GNUisms, and forget simple facts, like how Bash and especially Perl aren't guaranteed to be installed on all systems. Sometimes I also wonder: does Kakoune set `-o pipefail` or `-o errexit`? If somebody sets `ENV` and does something fishy, will that make my text editor unlaunchable? Behavior rooted in common semantics rather than heavy syntax (Bash, Perl) or micro-languages (Awk, Sed) make the overall experience much more pleasant. Especially if you do something like Neovim (Awesome, etc.) and use Lua for Config so you don't have to reinvent anything


> This doesn't just leave a bad taste in my mouth - it is also a giant waste of resources and causes initialization to be substantially slower compared to the alternative

I agree that shelling out on a whim that Kakoune does is a tremendous waste of CPU cycles as the OS needs to construct and tear down a whole process just to do something trivial. Having said that, in day to day usage, kakoune feels quite responsive. It's also easy to hack up plugins really quickly.

Shelling out is a crude way of getting some parallelism also. You might be surprised that constructing a new thread vs constructing a new process in Linux is not that much different resource/latency wise. Since bash/dash code is probably cached in the system memory somewhere already and libc etc are again dynamically shared, it may not be as bad to construct a whole new process. TL;DR it's bad but maybe not as bad as one thinks. It's definitely avoidable and I would not design it this way myself. I remember having to shell out once because kakscript does not know how to increment 1 to a variable and I needed dash to do that! That was one expensive +1 calculation! and I can almost imagine my CPU heating up!


> (Posix) shell scripting is just everywhere and is an important skill to have.

Not on Windows.

Which may or not may matter.


Didn't Microsoft team up with Ubuntu to offer this to Windows users?

I'm out of the loop and haven't touched windows seriously in years (other than to fix WiFi or printer issues for family. Sigh), so I probably misunderstood this Ubuntu in Windows completely.


It's through WSL and it's still not native or seamless.

You can't ask a regular Windows user to have it set up as a dependency.

I can't just go "wsl.exe" and have a very clean and seamless integration into Windows and pretend that "wsl.exe" is just another shell like cmd.exe or powershell.exe, WSL is it's own box off in a corner.


//Supports all operating systems except windows?! Oh the humanity! When will the discrimination end?//

I love a good editor. I just discovered Joe and am super happy with that. Cross platform key-bindings is very important considering I am using many different operating systems.


> When will the discrimination end?

When all developers finally finished moving away from Windows :)


I run across this editor from time to time, but I'm in my 50's, and I'm pretty sure emacs will continue to be good enough for me through retirement, and I just don't feel like learning a new one. I even know enough vi(m) to get around; surely I won't need more than BOTH of those in the next 10-15 years.

IDE's, sure, but for editing... nah. Most of the IDEs even have passable emacs keybindings, or the ability for me to make one (or use a FOSS one that someone quicker than I am has already done).


Hmm, how would you replicate the alignment operation they show in the gif using vim? I couldn't immediately think of how to do it.

I guess you could select the block, then maybe s/\>\s\</\=repeat(' ', 20 - col('.'))/g?

That doesn't feel like the right solution though... maybe a macro, something like qa^wi<Tab><Esc>q then visual select and :norm@a? I dunno.


I use the vim easy align plugin for that. You could replicate it with "ga2 ", so go align 2nd space seperated. There are a few alignment modes for the last character (instead of the space), e.g. "|" for markdown and "&" latex tables.


The person that decided on the launch command 'kak' is not Dutch for sure :)

Though I guess most 3-letter words mean something bad in one language or another :P


I end up mentally pronouncing kak like "cack" (https://www.lexico.com/definition/cack) every time. Makes kakscript sounds pretty weird too.


Yup,

Same meaning for Afrikaans.

Although Afrikaans is derived from Dutch some very rude words in the one are absolutely fine in the other for both.


Is the extension language kakounescript documented somewhere ? I am having a hard time finding a reference. I wish they just used lua/js though.


Kak is mostly self-documenting, but there are a few :doc pages that give more detail. Of particular interest are the commands [0] and command parsing [1] pages. Those will get you started.

Kakscript does not have any control flow beyond a simple try/catch mechanism - for anything complex, you use shell scripting [2]. It is both a blessing and a curse - making it extremely easy to integrate with other tools, but causing some pain if you don't know shell scripting already.

[0]: https://github.com/mawww/kakoune/blob/master/doc/pages/comma...

[1]: https://github.com/mawww/kakoune/blob/master/doc/pages/comma...

[2]: https://github.com/mawww/kakoune/blob/master/doc/pages/expan...


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

> The first thing to realize is that non-modal text editors are extremely biased towards insertion.

I made https://enso.sonnet.io and I 100% agree with Maxime on this one


It seems to be a decent editor. I did not like the kak config files and the syntax it uses for some reason. That’s one of the main reasons I stayed away from it. Gonna check again to see if anything changed.


> I did not like the kak config files and the syntax it uses for some reason.

Maybe I have Kakoune Stockholm syndrome but I actually like the syntax of it's config/script files.

- The "kakscript language" is really quite minimalist. This makes it easy to remember and extremely consistent. It is designed to serve as a "glue" language rather than a fully powered language.

- To write plugins you have to work with kakscript and (Posix) shell script (bash, dash etc.) or a basic shell script that in turn works with a program written in another language (Perl, Python, Rust etc.). It's difficult to explain on HN but the kakoune<->outside world integration is one of the nicest I've seen. There is very little ceremony and you can be up and running really quickly.

- The creator of Kakoune is very reluctant to add more features to kakscript. While languages around us quickly accrue features and syntax, keeping kakscript limited means that you are forced to write more complicated code in languages that have been designed to be truly general purpose and not in kakscript


Anything in there that would make an avid vim user to switch?


Can anyone point me to the documentation listing the modal commands? I can't find it in the editor itself or on the website

EDIT: I figured it out. Type ":doc keys"


Finally, a full rank editor. Needless to say the best part is the orthogonal design. Emacs and others compared to this have zero determinants in their favour.


Emacs is the best editor with kakoune keybinds, but I'm not letting you play Cunningham's law on me.


No, I was making a maths joke on count of the "orthogonal design" on their website. Orthogonal matrices are full rank and have non zero determinants, but I think it was perhaps a bit too well disguised.


I'd like to try, but it does not support translations. I prefer using software only in my native language.


Anyone knows where the name came from?


It means "kick", "hit". See one of the comments here: [0]. Also (if you speak French) this: [1]

[0] https://www.reddit.com/r/vim/comments/1tdiap/kakoune_a_longd...

[1] https://fr.wikipedia.org/wiki/Fran%C3%A7ais_de_Nouvelle-Cal%...


Japanese for "let's write". (書こうね)



> Japanese for "let's write". (書こうね)

So it's pronounced like kah-kooh-neh or similar.

Three syllables, drag out the middle "oh" sound a bit longer.


that video in the bottom of the page looks pretty neat! ofc everything will look magic when I've use to bloated VS Code for daily stuff


Vim inspired. Nice. I’ll give it a shot


Linux X11/tmux only.


macOS & FreeBSD too, and under WSL on Windows obviously.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: