What is Reddit's opinion of Kakoune?

Seriously, if you're trying to learn vim, then kakoune (github) is easier. It shows you what it is doing and you act on selections that are viewable. And it's pretty similar in keystroke efficiency as vim.

Indeed I think that's the case for a few languages. For what it's worth, the name "kakoune" comes from a New Caledonian dialect.

Another user reported that "kakoune" is homophone to "let's write" in japanese, which is a pretty cool coincidence.

Not OP, but: I just ran a quick benchmark, using tar -czaf test.tar.{ext} to compress the source code of a moderately large open source project*. Here are the stats:

Compressing with xz took four times longer than with bz2 (81.22s versus 19.17s)
The xz file is 18% smaller than the bz2 file (67M versus 82M; for reference, the original code was 244M).
The xz file takes 58% less time to decompress than the bz2 file (2.90s versus 6.98s; note that this was just decompressing the tar file, not fully extracting the archive.)

So I would say you should stick with bzip2 unless disk space is at a serious premium, or the file will be decompressed much more frequently than it will be recreated and recompressed.

* Kakoune, if you'd like to reproduce this experiment.

Absolutely https://github.com/mawww/kakoune -- I honestly like a lot of its core ideas more than vim, nvim, xi-editor, sublime, atom or emacs.

Pros

ready today (it isn't theorycraft, it is real, it is usable, it is featureful)
minimalist (handle windows layout using tmux or similar)
selection oriented (https://vimeo.com/82711574) -- they are multiple, and directed, and amazing and are a brillent design choice.
orthogonal design
efficient (fairly consistently beats vim in golf challenges: https://github.com/mawww/golf)
client/server
syntax highlighting is per window, multiple per file
really clever hooks system
great integration with running shell commands
(lots more)

Cons

stupid (joke) of the paperclip is actually built into the app (can configure it away)
learning curve from vim is -- complicated because a lot of your muscle memory will work then randomly not based on where it fits / doesn't fit
beastly cpp/boost app -- yuck, but fast.
poor documentation (an undocumented feature is a useless feature)

wm - herbstluftwm
dotfiles - https://github.com/boj/dotfiles-nixos
editor - kakoune
shell - fish + oh-my-fish

Been using the kakoune vim alternative for the last 6 months and absolutely love it. Hopefully they merge my PR for this new theme I whipped up today.

To compose commands is really a powerful concept. One thing that annoys me is that you have to input the full key sequence before you get feedback. Editors like Kakoune reverse the order: You first select things and afterwards apply the operation. Another neat idea is Versor where you select one unit and afterwards move by it's units with the same keys for any unit you select. I have implemented something like that but using text objects and temporary modal states:

For example the command beginning-of-defun automatically "locks in" the defun text object. Now pressing n moves to the next defun, p to the previous, k kills the current one, m marks it and moves to the next (like you would mark a file in dired). When you have marked multiple objects pressing k acts on all of them sequentially. You can also switch the locked in object and mark different ones. After applying an operation you are back to normal. You always get into that modal state by pressing a movement command associated with an object, beginning-of-paragraph "locks in" the paragraph object, backward-sentence the sentence object and so on. I still have to publish it but I'm a bit struggling to finish it.

Kakoune doesn't have something equivalent to set undofile: https://github.com/mawww/kakoune/issues/2021

It is a hard feature to implement correctly and AFAIK the only terminal editors that support it are (Neo)Vim and Micro.

I mean it's almost the same question why you'd use clang over gcc, or distro X over distro Y.

I haven't exactly used it for long enough to have a fully crystallized opinion on it 'versus Vim', but maybe the design doc will shed some light there.

^(For what it's worth though, I definitely enjoy the fact that it seems much more ...featureful out of the box than Vim; yes, Vim's extremely extensible but customizing it can be a task in and of itself sometimes, unless it's just me who has a hard time managing Vim plugins.)

Like, yes, if you're a big-time Vim junkie and Vim already does everything for you that you need it to do then more power to you, but there is no reason why Vim should be the only console text editor in town.

As someone who started using editors with multiple cursors a lot, like Brackets and the IntelliJ IDE's, having multiple selections was big when I was recommended vim. I looked around and saw the usual options for multiple cursors in vim and all the options seemed like crap. I did however stumble across a demo I had seen a while ago for a editor called Kakoune. https://github.com/mawww/kakoune

Kokoune is vim-inpired and the editor is completely based around using multiple selections. There aren't many people using it but the dev is constantly working on it.. It doesn't have all the bells and whistles of vim yet, but I found Kakoune to have some amazing design ideas for what a multiple cursor text editor should be.

I've been using a very similar system to what he describes for a long time in C++, I learned about that around 10 years ago at Eugen Systems, and I've been using it either since:

I call those SafePtr, they are trivial to implement in C++, as they are basically ref-counted object which validates that the ref count is 0 in its destructor. See https://github.com/mawww/kakoune/blob/master/src/safe_ptr.hh for an implementation (this supports tracking callstacks where a pointer was created to help debug dangling SafePtrs).

The C++ implementation is strictly more powerful than what is described here as an object lifetime could be maintained by any mean (could be on the stack, could be a unique_ptr, could be shared_ptr, or whatever you fancy), the SafePtr just ensures that no such pointer outlive the actual object.

They are also sometimes painful to work with as it is the existence of a dangling pointer, not its usage which will raise an error, leading to sometimes convoluted code just to ensure SafePtrs are cleared before their pointee dies.

You can easily disable it with the following option command that you can put in your kakrc:
set-option global ui_options ncurses_assistant=off
And if you want you can even set this assistant to cat or dilbert, I'm sure that compensates for the built-in clippy

https://github.com/mawww/kakoune/wiki/Migrating-from-Vim: Read the composing commands section

Nice write up: https://www.reddit.com/r/vim/comments/5icmak/a_vim_users_comparisation_between_kakoune_and_vim/ (See the first comment for a formated version, so you can skip the parts you don't want)

I have about 15-16 years of Vim under my belt, recently switched to Kakoune. Some things just feel better-thought-out and it has multiple selections built in by default.

> started learning vim but it's not working correctly in tmux (the Ctrl+Arrows for moving to next/prev words)

For all that terminal emulation is a venerable and stable technology, it's still pretty unreliable when it comes to non-alphabetic keys, so I'm not too surprised here. Kakoune, being a terminal-based editor, doesn't handle ctrl-arrows either. I might see how hard it is to hack that in.

> also, vim always inserts spaces when adding lines to a file, even if the file uses tabs.

Vim has the expandtab option to determine whether to insert spaces or tabs, and the :retab command to "fix" existing identation. Detecting whether a file uses spaces or tabs for identing is difficult, especially with Vim's softtabstop option that uses both.

> apparently there's no real working substitute for vim that works with auto-completion etc., is that true?

Vim is fundamentally a single-cursor editor. It does let you select the same area on consecutive lines, but that's really just one selection. It lets you perform the same operation in different places across the buffer, but one-at-a-time, not in parallel.

> Have you used Sublime and would you recommend switching to Kakoune instead of switching to vim/neovim/oni?

I haven't used Sublime, but it sounds like you expect a certain level of polish from your editor (an attitude I can certainly empathise with!) so I can't tell you to switch immediately and everything's going to be fine (for example: where Vim has an option to insert tabs or spaces, Kakoune has user-submitted scripts).

That said, if you're feeling a bit adventurous and want to try out something new, I definitely recommend giving it a shot, even if only for a few days.

Petits plugs pour mes logiciels favoris:

kakoune: un éditeur de texte moderne pour terminal, inspiré par vim mais en mieux (à mon humble avis). Très bon design et une implémentation encore meilleure. Je maintiens quelques plugins pour.

mpv un lecteur vidéo multi-plateforme léger, efficace et puissant. Y'a moyen de faire un tas de trucs sympas grâce à son API. Là encore, je maintiens quelques plugins.

elvish un shell (comme bash, mais pas POSIX) moderne sans les chausse-trappes classiques du shell. Il supporte de vraies structures de données (array et map) sans les représenter par des strings. Très agréable à utiliser interactivement.

Don't worry, clippy can easily be disabled with the following option command that you can put in your kakrc:
set-option global ui_options ncurses_assistant=off
And if you want you can even set this assistant to cat or dilbert

Awesome! I've been looking for a concise way to explain my love for Vim over most GUI text editors (especially ones focused on a specific language) and this is pretty spot-on.

As an aside, I think anyone who loves Vim should definitely try out Kakoune. My experience is that it basically takes the Vim paradigm and makes it even cleaner and easier to use in very significant ways. I switched to Kakoune a few months ago and haven't looked back (but I'll always have a fondness for Vim, of course :) ).

> they haven't really touched the vimL, which is really where most problems are.

ZyX has made significant progress on a VimL to Lua translator:

https://github.com/neovim/neovim/pull/243

> we need a modern modal editor that is vim-like to replace vim.

There are many of those:

> I've given thought to actually writing one, but at this point I just have a roadmap

You could save a lot of work by using neovim as the core of your new modern editor. I'm curious about why you think that wouldn't be valuable. No vimscript involved, you can (soon) communicate with neovim via msgpack, json, or C ABI.

If you're starting from scratch you might want to look at kakoune, it's a more modern take on modal editing. It also has good lsp support, so you can reach a level of integration comparable to an IDE with certain languages (I use it on a large C++ codebase, it's great).

You should have a look into the BufWritePre hook, combined with %, | and your command-line program.

edit: there is also a formatting-related builtin script here. You can declare the formatcmd to be elm-format and then just call the command format, or hook it to BuffWritePre to run it automatically.
For more advanced usage, you can also change the formatcmd variable to be set dependending on the filetype.

Vim doesn't have multi-cursors, but the two other things are supported either out of the box or with plugins.

A vim-like editor with multi-cursor support you might want to check out is kakoune.

This is the behavior of kakoune, a vim inspired code editor see https://github.com/mawww/kakoune#11-features

> Client-Server architecture > Use tmux or your X11 window manager to manage windows

Well, there are projects like https://github.com/mawww/kakoune: kakoune is vim-like in many ways: it shared many vim commands, it's light, it runs in the terminal, it has text objects, it tries to minimalize characters-typed-per-actions, etc, however it also is not trying to stay completely compatible even where it "could" (e.g. similar but different fundamental movement commands, ~ is <A-`> instead) because it is trying to be a little more radical and actually improve on the vim editing model without pursuing backwards compatibility just to be like vim (rather, it only matches vim where kakoune's author considers vim to be doing the right thing already, it seems).

Kakoune currently makes my head hurt like vim did at first (and it's not complete, doesn't have that much plugin support, etc) but it's pretty cool. It acknowledges like other programs don't that we'll probably want to change some of vim's core behavior eventually (I don't want whatever editor I use in 2060 to ship with vim's default delete/put register behavior, for example...).

Kakoune is a vim-like text editor, and lf is a file manager almost exacly like ranger, but written in go (performs much faster in my experience).

No, there is no shell emulation within kak, this would run counter to its philosophy of collaborating with other unix citizens. There is help on various topics, try :help or :doc and then select your topic of interest (from "buffers" to "scopes") with <TAB> or fuzzy completion. There is a tutorial for beginners, not as complete as vims's but still very good IMHO:

https://github.com/mawww/kakoune/blob/master/contrib/TRAMPOLINE

NB: by the way, the fact that all completions are fuzzy is another of Kakoune's advantages.

>One of the things I missed when I switched from Vim to Kakoune for a few days was gv (restore previous visual mode selection). In general it felt like messing up a selection wasn't "undoable". I wonder if that's a solvable problem.

You can save your selection is a mark:

https://github.com/mawww/kakoune#marks

> Why would that go against text objects?

I just meant there is no "direction" for those operations, so there is no logical reverse direction.

> Another difference of kakoune marks to Vim marks is that there isn't a special namespace for them, they go into registers too. I don't really see the direct benefit of it, maybe more flexibility in scripting? Are there automatically set kakoune registers that make sense to be used together with z?

Yep, registers are just variables that can store anything in Kakoune. What you save in it can be in different formats though, so a mark you create from a selection won't be the same as just yanking it.

^ is the default register for marks, others are documented in :doc registers default-registers; also worth looking at the other registers in that help page. If you ask me I just use Z and z with my previous saved selections, which would be in ^ and not need to be explicitly specified. Maybe it would make sense with integer registers for special operations.

> I couldn't see whether there's something special about uppercase registers

They are same as lower case registers right now, so one would overwrite the other. There is an old PR here to replicate Vim behavior here, if you are curious: https://github.com/mawww/kakoune/pull/1630

The problem you're running into is the fact that there is no "command" <end> in Kakoune, i.e. there is nothing to map to. <end> is internally mapped to <code>&lt;a-l&gt;</code>.

If you wanted to map <c-e> to "the same thing that <end> does", you would need to map global normal '<c-e>' '<a-l>'. If you want to map it to "move cursor to the end of the line without selecting", it's map global normal '<c-e>' 'gl'.

I m afraid that might not be possible. Colorscheme command as defined simply looks for the parameter in certain folders and sources the found file. It doesn't preserve the parameter in an option or such. Only way you might infer the active colorscheme would be through something defined in the sourced file.

I've been down this road. It's a painful dead end. If you like Kakoune, you are better off just using Kakoune (or trying the VSCode or Emacs plugins for Kakoune). Yes, its keybindings in theory are debatably better than Vim's since you always know what text you're acting on before you act (also, see counterargument), but it's a VHS/Betamax exercise in frustration.

If you really are up for this quest, then I suggest going through this page extensively. You'll have to use modifier key combos (ALT) to handle all sorts of actions like J and $ and 0 and ;, which is actually the easy part. Then you have to look at how commands work with : and all the search/replace nuances. You'll either wind up with a partial implementation or Kakoune's features, or be chasing your tail trying to figure out how to make every feature work. And, then if you succeed, good luck ever using any vim plugins with keybindings. I do hope you succeed where others have not.

As someone who switches between editors quite often, I think this is a very interesting avenue to explore -- similar to vis and kakoune. The latter tries to "modernize" vim's editing language, whereas vem seems to ditch it completely, or at least making it quite monosyllabic.

And congrats on the presentation. This could as well been a personal vim config and blog post, but instead you get a quite decent installation experience and extensive documentation.

That will make me at least try that.

Sorry, I misunderstood your question. I thought you were asking referencing capture groups when pasting. I just realized you were asking about referencing capture groups when selecting, and specially, in the case of `(\w*)=\1`. I didn't try the command, I replied on my phone. My bad.

Then it maybe just the limitation in Issue 2486. I myself wonder how to select `(\w*)=\1` in Kakoune too.

There is Kakoune's trampoline. See this link:

mawww/kakoune/blob/master/contrib/TRAMPOLINE

The trampoline does not seem to be included in all distributions. If you don't have it installed, you can always download it from this link and open it in Kakoune. It is far less polished than vimtutor, but I still found it very helpful. For more detailed help about faces, hooks, commands, etc., type :doc <TAB> to see a list of available topics.

I agree with most of your points, but the positives still outweigh the negatives for me by a large margin. Below are a few comments on your remarks:

re: diff mode: This is the biggest thing I miss from Vim also. But I still have Vim installed with my config, so I keep using Vim for diff and kakoune for everything else. I'd prefer to use kak but I don't see it as a very big deal to use a separate editor for diffing.
re: indenting: smarttab does what I want, but I don't use editorconfig. However the quality of indent hooks depends on the language and some are worse than Vim's.
re: 24-bit colors: I haven't run into issues with this, but I did have to install the tmux terminfo file. I am not a fan of the idea of installing terminfo from an editor repo, but I haven't run into any problems with it so I can't complain. FYI there is a non-ncurses branch that is pretty stable and AFAIK doesn't do palette switching.
re: docs: This is a pain point compared to Vim and there seems to be a consensus in the community that it needs to be improved.
re: debug info: There are a few entries under debug command such as debug mappings and debug faces that would help. It definitely isn't as comprehensive as Vim's whole verbose system though.
re: read/write hooks: I am not sure if you were already involved in the discussion but it is an issue that recently came up here also.

If you have your linters installed you have to configure them to run on save within your kakrc. Here’s an example configuration.

https://github.com/mawww/config/blob/master/kakrc

It shows how to configure flake8 specifically. I’ve never used cppcheck specifically so I can’t comment on that, but it’s not hard to setup custom punting support for your favorite linter. Below is a link to a simple shell script I wrote to add joker support to kakoune. Joker is a Clojure linter I really like.

https://github.com/w33tmaricich/clj-kakoune-joker

All you have to do to add support is format your linters output to a specific format kakoune expects.

Also found this link that shows how to configure cppcheck.

https://github.com/mawww/kakoune/wiki/Lint

Did you see the wiki page for the builtin lint.kak? https://github.com/mawww/kakoune/wiki/Lint

I mainly use kak-lsp and its lsp-diagnosticscommand, but pylintusing the builtin lint also comes in handy.

You might want to try the readme in the github repo, or the trampoline walkthrough. i would say in some ways Kakoune should be more beginner friendly than Vim, since it's much cleaner design (no strange hidden modes etc.) and you can generally see what you're doing with the selections better, but then I came from years of vim so I'm not sure it would feel the same starting afresh.

I'm in the same situation as you. I'm not sure if vis is already for usage. I'm considering trying kakoune though, much more minimalist than vim, and is more mature than vis

There's also kakoune. Which is not exactly suckless level in terms on minimalism, but t puts a great emphasis on following the unix philosophy. It's also much more mature than vis.

There is no documentation for this specifically. To figure it out on your own, you'd have to find it by reading the source.

It's quite simple though. Add this to your config:

hook global BufOpenFile .* %{
    modeline-parse
}

If you change a file and want to re-apply its new modeline without closing it first, run the modeline-parse command directly (or add it to ModeChange or BufReload hooks, but that's probably overkill).

Sure. Here's a Bitwig Studio controller extension I wrote. Here's a pull request that was merged into the modal editor Kakoune. Here's an open pull request for the Base16 project. I'm not a professional developer, but I try to contribute when I can. :)

Kakoune string implementation provides 23 bytes for the small string buffer, looks like that:

// String data storage using small string optimization. // // the LSB of the last byte is used to flag if we are using the small buffer // or an allocated one. On big endian systems that means the allocated // capacity must be pair, on little endian systems that means the allocated // capacity cannot use its most significant byte, so we effectively limit // capacity to 2^24 on 32bit arch, and 2^60 on 64. union Data { struct Long { static constexpr size_t max_capacity = (size_t)1 << 8 * (sizeof(size_t) - 1);

char* ptr; size_t size; size_t capacity; } l;

struct Short { static constexpr size_t capacity = sizeof(Long) - 2; char string[capacity+1]; unsigned char size; } s; ... }

(Full code at https://github.com/mawww/kakoune/blob/master/src/string.hh#L159)

As far as I know, there is a single undefined behaviour in it, which is the is_long() const { return (s.size & 1) == 0; } method (as we dont know which union member is active).

I think this can be solved by using reinterpret_cast<const char*>(this)[sizeof(Data)-1] instead.

kakoune も

# clippy|cat|dilbert|none|off set-option global ui_options ncurses_assistant=cat

とかやるとテンション上がります
なおユーザが設定ファイル等で自由に設定できるようにはならない予定だとか

https://github.com/mawww/kakoune/issues/1753#issuecomment-351277679

You can try the builtin-terminal-ui branch, which supposedly handles true colors differently. As a bonus, it is even easier to build since it does not need ncurses.

I adopted kakoune yesterday after reading this blogpost.

I recommend adding a link to this really short-starter guide for kakoune: https://github.com/mawww/kakoune/blob/master/contrib/TRAMPOLINE in the article.

I don't see a link to it in the aforementioned blogpost.

But it is the reading and using of this really short guide which made me jump in a matter of minutes from: "i am testing this cool app and I stumble on some stuffs" to "wow, nice, I'll use it from now on"

m2c

There's a lot of potential reasons — in a lot of ways it tries to be a better vim by being unconstrained by the legacy of vi¹. I'd recommend checking out the extensive README. If t don't have time for that, then you probably don't have time to learn a new editor.

I haven't tried it out yet, but I'm intrigued.

That's one of kakoune's design features, there is no difference between scripting and interacting with kakoune. You can think of all scripts as sort of macros, which act out commands for you.

This design decision is stated under design notes.

Apart from the README, see also the <code>doc</code> and the <code>doc/pages</code> folders in the repo (contains the same info you get with the :doc command) as well as the wiki on Github.

The code examples are rarely explained.

Well on the Kakoune website there's a link called "Documentation" that takes you here:

https://github.com/mawww/kakoune/blob/master/README.asciidoc

You also get help in the editor in a pop up when typing commands.

Solved.

For some unknown reason my awk can't use {} as expression iterator in regular expressions.

That means that /^([0-9a-f]{40}) ([0-9]+) ([0-9]+) ([0-9]+)/ {

in line 79 of https://github.com/mawww/kakoune/blob/92972bed4fb4ff6dffd32169bc437de34acac6a9/rc/tools/git.kak

Cant be processed well. Replacing that for /^([0-9a-f]+) ([0-9]+) ([0-9]+) ([0-9]+)/ { works pretty well.

compiled limits:

max NF 32767

sprintf buffer 2040

its the default I guess in Ubuntu 18.04

Modern terminals have a palette of 256 colours, where the bottom 16 can generally be configured by the user, and the rest typically default to a standard set of generally-useful colours. The problem occurs when you use a colour scheme that demands a specific RGB colour - it's almost certainly not in the standard set, and there's no good way to tell if it's in the user-configured bottom 16, so Kakoune has to modify one of the standard set of colours to match.

The only way to avoid this is to prevent Kakoune from trying to set colours at all. Most terminal colour schemes are designed to be compatible with the bottom 16 colours, and those colours are user-configurable, so configure them to be the colours you want to use, and then modify the Kakoune colour-scheme to use those bottom 16 colours by name instead of by RGB value.

It's possible for a completion menu to appear even with whitespace to the left of the cursor (such as when using kak-lsp for completions), in which case those hooks make it impossible to use <tab> to indent things. The wiki has a slightly more complex hook that makes tab and shift-tab cycle completions only if not following whitespace.

Specifically the last comment before the issue was closed, yes!

As pointed out on IRC, that solution has the slight drawback that if you're using a super-smart completion engine it may provide completions before you've typed anything, preventing you from actually inserting tabs, but I'm pretty sure that won't bite me any time soon.

I'm still interested to hear about solutions that avoid that issue, though!

tmux je suis pas fan du tout, c'est un merdier monstrueux à faire fonctionner correctement (bonjour escdelay) tout ça pour faire le job de ton window-manager mais en moins bien.

Sinon je propose kakoune, c'est vim mais en mieux.

I found a bug report for this: https://github.com/mawww/kakoune/issues/997 so I guess it's a known issue.

I to remap, but

map global , <a>

remaps , to a, instead of remapping it to alt. There doesn't seem to be a nice easy way to remap the alt key to something else.

edit: found a solution.

> enum class like thingy suitable for bit flags, which would allow bitwise operations while preserving scope rules and safety of enum class

This is already relatively easy to do:

flags.hh

Just declare constexpr bool with_bit_ops(Meta::Type<MyEnumType>) { return true; } just after you enum class definition to opt-in flag operator support.

I'm myself a proponent of advanced text editors (kakoune for reference) rather than IDEs, but I'm dubious of the claims that they are "much more efficient".

There are good reasons for learning to use a powerful text editor, and they will be more efficient for certain tasks. But they also fall short when it comes to truly understanding the programming language and project you're working on, and an IDE will be able to propose advanced completions and refactoring that text editors just can't do.

You can find some information about autoloaded plugins here.

Basically you can copy the file to .config/kak/autload/ (don't forget to make a symlink there to /usr/share/kak/autload in order to continue using all the default plugins).

Note that the "plugin" doesn't come with a default binding, you can just add something like: map -docstring "itersel" global user r :interactive-itersel<ret> to your kakrc file.

It was removed as part of this pull request: https://github.com/mawww/kakoune/pull/1300

It looks like you should be able to lenormf's kakoune-debian repo to create a package for kakoune and install it that way.

Also, someone has put up this package: http://packages.ubuntu.com/zesty/kakoune

Just be aware that mawww is not a primary Debian/Ubuntu user so he does not want to maintain packages for Debian. These packages are all maintained by other community members. (See https://github.com/mawww/kakoune/issues/1004)

Strike that. I was looking in the wrong place, here it is: https://github.com/mawww/kakoune/blob/master/rc/core/comment.kak

This doesn't support YAML though. Or any other format which doesn't do block comments.

> The individual language scripts define how commenting is done.

Can you point me to an example? I've been looking in the <code>rc</code> directory but I can't find anything language related. I'm trying to get the YAML comment-selection to work.

What does orthogonal design mean (Kokoune)?

Edit: Answer in doc/design.asciidoc and on [Wkp](https://en.wikipedia.org/wiki/Orthogonality_(programming\)).

I was just wondering whether one could use a modeline to select per-file whether to use tabs or spaces (different people/communities enforcing different coding conventions), and stumbled across this:

https://github.com/mawww/kakoune/blob/master/rc/extra/modeline.kak

Alas, in VIM I would often use things like this:

:set tabstop=4 softtabstop=4 shiftwidth=4 noexpandtab

For indentation with tabs, specifying the visual width. Hower this would lead kakoune to indent with 4 spaces (as shiftwidth is translated to indentwidth and noexpandtab is ignored).

Should be possible to extend this script to do an indentwidth=0 if it sees a "noexpandtab", what do you think?

I wouldn't rule out the non-optimized build yet, I'm trying with a file of the same order of magnitude (2M lines, 3M selections) on an oldish laptop and while everything is sluggish, the operations that you mention finish in <5s (each so that's still a lot slower than vim but I guess that's where the paradigm difference comes in). Try building it from the repository directly. Also on a buffer that big I'd recommend set buffer incsearch false.

For more in-depth answers, it's probably best to ask on github or IRC where the author can answer you directly.

edit: yeah this seems to be the homebrew recipe thing, it doesn't look like it's being built with optimizations.

Well, look at the first source file I viewed:

https://github.com/mawww/kakoune/blob/master/src/backtrace.cc Manually managing memory in the code that can throw exceptions is a recipe for memory leaks.

But don't trust me - send a link to this GitHub repository to /r/cpp and see what they have to say...

I switched from Sublime Text to Visual Studio Code to Kakoune.

I tried vim/emacs but really missed the highlighting, duplicating, multiple cursors out of the box of sublime text / vs code.

That's why I recommend you try out kakoune if vim/emacs doesn't work out for you. Visually shows you what's happening, has multiple cursors out of the box, and easy to pick up. I was doing everything I did in sublime/vs code within a week at equal speed. A couple more weeks and it was appreciably faster. Very awesome editor which I would not mind helping you set up / adjust / figure out if you were inclined to try it out :)

http://kakoune.org/

https://github.com/mawww/kakoune

and #kakoune on IRC

There's also the kakoune editor which is basically vim with only visual mode instead of normal mode. The nice thing is that you can always see which part of the text you're going to change.

What is Reddit's opinion of Kakoune?
From 3.5 billion Reddit comments

➔ Kakoune website

By popularity on Reddit, this Service is:

67 reviews of this app found across Reddit:

What is Reddit's opinion of Kakoune? From 3.5 billion Reddit comments

➔ Kakoune website

By popularity on Reddit, this Service is:

67 reviews of this app found across Reddit:

What is Reddit's opinion of Kakoune?
From 3.5 billion Reddit comments