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.
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âŚ)
You can also just setup an org, a better fit for most open source projects as you can hand it off in the future.
This is really awesome, thanks for your work on it.
The example that made me think, âThis is huge!â (from the playground example file):
...
# 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.)
1 Like
It can even do it on on selected text! @alexherbo2 showed me kcr pipe jq '.[-1:] + .[:-1]' # reimplementation of the builtin rotate_selections_content()
For what my two cents are worth, I think if a plugin needs a separate tool that:
- Isnât trivially easy to install with a standard package manager
- 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
- Kakoune simply doesnât do enough on its own to provide a good user experience
- 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.
6 Likes
@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).
4 Likes
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.
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.
1 Like
Sounds like a 3rd requirement @CBenoit, possibly the hardest one:
- Must not impact startup time too severely