# Kakoune.cr **URL:** \ **Category:** Terminal Tools\ **Created:** [February 24, 2021, 10:10am UTC](https://discuss.kakoune.com/t/kakoune-cr/1605 "2021-02-24T10:10:24Z")\ **Posts on this page:** 10\ **Page:** 3
**Author:** ![Ordovician\_Dawn](https://discuss.kakoune.com/letter_avatar_proxy/v4/letter/o/82dd89/32.png) [@Ordovician\_Dawn](https://discuss.kakoune.com/u/Ordovician_Dawn)\ **Post date:** [March 28, 2021, 11:36pm UTC](https://discuss.kakoune.com/t/kakoune-cr/1605/41 "2021-03-28T23:36:30Z")
I like reading through the code of kak plugins written in various different languages (I might not have thought about trying Crystal were it not for the complaints in this thread! 😉) Looking forward to using kakoune.cr. ---
**Author:** ![Ordovician\_Dawn](https://discuss.kakoune.com/letter_avatar_proxy/v4/letter/o/82dd89/32.png) [@Ordovician\_Dawn](https://discuss.kakoune.com/u/Ordovician_Dawn)\ **Post date:** [March 30, 2021, 10:52pm UTC](https://discuss.kakoune.com/t/kakoune-cr/1605/42 "2021-03-30T22:52:13Z")
> Looking forward to using kakoune.cr. Well, I’m having some fun playing around with it — had to install Crystal, which was version 1.0.0, and which wasn’t supported yet, so then (not knowing Crystal) I decided just to alter the Makefile so as to ignore version number. Version 1.0.0 was released only a week ago, so I’m not going to complain too loudly about it! But I look forward to knowing I can install the current version of **kakoune.cr** on the current version of Crystal. Some things aren’t working — _list_ hangs and _pipe_ spouts a Crystal JSON error — but I can send files and commands to kakoune, which is exactly what I wanted! Now I can start work on my amazing tmux-based kakoune IDE. (I suppose I should create some GitHub issues, but I want to create a completely new GitHub account for new work, and that will take me a bit of time…) ---
**Author:** ![robertmeta](https://discuss.kakoune.com/user_avatar/discuss.kakoune.com/robertmeta/32/833_2.png) [@robertmeta](https://discuss.kakoune.com/u/robertmeta)\ **Post date:** [March 31, 2021, 3:25am UTC](https://discuss.kakoune.com/t/kakoune-cr/1605/43 "2021-03-31T03:25:49Z")
> [@Ordovician\_Dawn](#): > > but I want to create a completely new GitHub account for new work You can also just setup an org, a better fit for most open source projects as you can hand it off in the future. ---
**Author:** ![alexherbo2](https://discuss.kakoune.com/user_avatar/discuss.kakoune.com/alexherbo2/32/1140_2.png) [@alexherbo2](https://discuss.kakoune.com/u/alexherbo2)\ **Post date:** [March 31, 2021, 7:25pm UTC](https://discuss.kakoune.com/t/kakoune-cr/1605/44 "2021-03-31T19:25:04Z")
Can you come on [Discord](https://discord.com/invite/uzZZG2X) to discuss it? ---
**Author:** ![jordan-yee](https://discuss.kakoune.com/user_avatar/discuss.kakoune.com/jordan-yee/32/592_2.png) [@jordan-yee](https://discuss.kakoune.com/u/jordan-yee)\ **Post date:** [March 31, 2021, 10:13pm UTC](https://discuss.kakoune.com/t/kakoune-cr/1605/45 "2021-03-31T22:13:03Z")
This is really awesome, thanks for your work on it. The example that made me think, “This is huge!” (from the playground example file): ```auto ... # Pipe selections to an external filter program # and replace the selections with its output. # # [1] kcr pipe jq sort ... ``` Seeing that you can run a `kcr` command in a terminal that’s open next to Kakoune in order to operate on the open buffer’s contents was my “oh, that’s what this does” moment. (Or at least one thing it does that I realized I wanted as soon as I saw it.) ---
**Author:** ![robertmeta](https://discuss.kakoune.com/user_avatar/discuss.kakoune.com/robertmeta/32/833_2.png) [@robertmeta](https://discuss.kakoune.com/u/robertmeta)\ **Post date:** [March 31, 2021, 10:19pm UTC](https://discuss.kakoune.com/t/kakoune-cr/1605/46 "2021-03-31T22:19:06Z")
It can even do it on on selected text! @alexherbo2 showed me `kcr pipe jq '.[-1:] + .[:-1]' # reimplementation of the builtin rotate_selections_content()` ---
**Author:** ![dead10ck](https://discuss.kakoune.com/user_avatar/discuss.kakoune.com/dead10ck/32/906_2.png) [@dead10ck](https://discuss.kakoune.com/u/dead10ck)\ **Post date:** [May 16, 2021, 7:53pm UTC](https://discuss.kakoune.com/t/kakoune-cr/1605/47 "2021-05-16T19:53:39Z")
For what my two cents are worth, I think if a plugin needs a separate tool that: 1. Isn’t trivially easy to install with a standard package manager 2. Has a separate install path from the plugin itself It will dramatically reduce the likelihood that the casual browser will choose to use the plugin. If people are looking at a plugin readme and see “requires this other CLI tool to work” and they need to do anything but add a plug.kak entry to their kakrc, they will probably think “Eh, pass.” Plugins like kak-lsp at least have the tool in the same source tree as the plugin, so it’s easy enough to set up your kakrc so that updates to the tool happen the same way as updates to the plugin. But if it’s a totally separate tool and code base, and you don’t use the tool for anything else, it’s just another thing I have to think about installing and updating. If the ecosystem were to end up with a bunch of plugins that depend on this tool that’s written in an obscure language, I feel it will drag kakoune down as a whole. It gives off the impression that 1. Kakoune simply doesn’t do enough on its own to provide a good user experience 2. The extra tooling I need to install just to get basic functionality out of the text editor is based on very nascent technology that requires too many manual steps to set up The value of kakoune being packaged by downstream Linux distros’ package managers cannot be understated. If the plugin ecosystem depends on a tool that’s not as easy to install, then that value is significantly diminished. Perhaps this is a topic for another discussion, but the fact that kakoune needs a separate tool like this just to reduce the pain of writing plugins says a lot about how much room for improvement there is in integrating with external tooling. With all of this said, @alexherbo2 please don’t take this as a personal criticism. I appreciate all of the work you do, and make heavy use of your plugins. But I say this because I’d like for Kakoune to succeed, and I believe honest constructive feedback will help this. ---
**Author:** ![robertmeta](https://discuss.kakoune.com/user_avatar/discuss.kakoune.com/robertmeta/32/833_2.png) [@robertmeta](https://discuss.kakoune.com/u/robertmeta)\ **Post date:** [May 18, 2021, 9:38pm UTC](https://discuss.kakoune.com/t/kakoune-cr/1605/48 "2021-05-18T21:38:27Z")
@dead10ck – I have had a few ideas spinning in my head on this topic for awhile… So, I think we can pull this off in a good way, I think here are the rules that must be followed: - Must be entirely installed by adding a line to your kakrc. - Must not pollute or depend on user system Now, the good news is – languages that can compile static binaries are GREAT for this – no matter how esoteric. Rust, Go, Crystal, C, C++ etc can all fill this role, and as long as plug.kak can detect your platform (intel-mac, m1-mac, arm-linux, arm64-linux, intel64-linux… etc) and those binaries are pre-built and under releases on github (or equiv elsewhere) in a standard way – plug.kak can get the newest one it expects. Honestly plug.kak might be able to do something similar now, but since the community is small, if it doesn’t, we can come up with a standard naming convention we can all follow package-current-platform.zip or some such. I think we can bring the power and richness of building your plugin in the language you want, with the joy of being able to copy and paste a line into your kakrc with no build time or additional overhead except downloading a binary. This continues to make me think that plug.kak should be a part of the kakoune project proper, but I don’t want it to slow development speed. But, I think this could be a major win – if we start building rich libraries in those languages to interact with Kakoune, we might even gain some new plugin authors who are really want to build their plugins in ($favlang). ---
**Author:** ![CBenoit](https://discuss.kakoune.com/user_avatar/discuss.kakoune.com/cbenoit/32/107_2.png) [@CBenoit](https://discuss.kakoune.com/u/CBenoit)\ **Post date:** [May 19, 2021, 1:15pm UTC](https://discuss.kakoune.com/t/kakoune-cr/1605/49 "2021-05-19T13:15:27Z")
> [@robertmeta](#): > > This continues to make me think that plug.kak should be a part of the kakoune project proper, but I don’t want it to slow development speed. This would really help for startup times as well. kakoune startup is actually faster than nvim, but when using plug.kak it can get at least ten times slower. > > > Install \`kakoune\` on Arch Linux from the official repo. > > Run \`kak -n\` — kakoun…e starts instantly (perfect). > Run \`kak\` — kakoune starts noticeably slowly, even though I didn't even create \`~/.config/kak/\` folder yet. > I use \`neovim\` with lots of plugins and huge config file, and it starts faster than \`kak\`. > > Given that I open and close editor many times during the day, it is essential to have the editor start as fast as possible. > > I'm not sure how I can provide more information to narrow down the cause of slowness. What does \`kak\` do, that \`kak -n\` doesn't? Calling the shell from time to time is not a big deal, but when packing up all the calls at startup, this is painfully slow. I’m considering starting my kakoune session with all the plugins at boot time with systemd and use a “plugins-free” version for my minor edits here and here. ---
**Author:** ![robertmeta](https://discuss.kakoune.com/user_avatar/discuss.kakoune.com/robertmeta/32/833_2.png) [@robertmeta](https://discuss.kakoune.com/u/robertmeta)\ **Post date:** [May 19, 2021, 5:46pm UTC](https://discuss.kakoune.com/t/kakoune-cr/1605/50 "2021-05-19T17:46:20Z")
Sounds like a 3rd requirement @CBenoit, possibly the hardest one: - Must not impact startup time too severely [Previous page](https://discuss.kakoune.com/t/kakoune-cr/1605.md?page=2)