What are /r/kakoune's favorite Products & Services?

From 3.5 billion Reddit comments

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.

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.

Side note I have another plugin

https://git.sr.ht/~parasrah/hestia.kak

That I use to safely load per-project configuration. , it's how I personally enable persistence for a project (so I'm not just creating .filelist.kak files anytime I open up kakoune). Also feel free to browse any of my other plugins while you're at it

https://sr.ht/~parasrah/kak-plugins/

Alright I managed to get something out of jump lists, it's actually not too bad: https://asciinema.org/a/6l5kr0nq0v7int50di4cbjn37

I used the two following bindings for that:

map global user s <c-s><space>i map global user n <c-o><a-space><c-s><space>i

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.

> 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>&amp;lt;a-l&amp;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.

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.

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.

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

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

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

&#x200B;

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

My awk version is
mawk 1.3.3 Nov 1996, Copyright (C) Michael D. Brennan

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!

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.

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.

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.

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.