A :lua command for Kakoune

Plugins
16

Hi, @TeddyDD! Thanks for the suggestion. Unfortunately, it works just until you realise you need the SESSION information in the first place. How do you get it? Additionally, I can’t write my kakrc in whatever language I want (like with my bspwmrc), because Kakoune parses it and so it needs to understand it. But let’s try to elaborate it a bit further to see what we get.

Perhaps what we need is an opaque kakrc together with opaque command definitions.

Suppose for a moment that, like bspwm, we have an hypothetical kakc client, used to communicate with the server (it can be a kak -p with some additional features). Also like bspwm, suppose Kakoune doesn’t read kakrc, just executes it. In this scenario, kakrc is opaque to Kakoune and so can be written in any language, say, Julia:

#!/usr/bin/env julia

# This is `kakrc` written in Julia

`kakc set-option global grepcmd ag`
`kakc set-option global aligntab true`

`kakc define-command a-new-command -params 2 mycommand`

If, then, the command a-new-command is invoked like this: :a-new-command \d+ 17, Kakoune does something along these lines:

export KAKOUNE_SESSION="the session number"
export KAKOUNE_CLIENT="the client from which the command was invoked"
mycommand '\d+' '17'

It allows us to write the custom command as an executable file called mycommand written, say, in Lua:

#!/usr/bin/env lua

-- This is file `mycommand`

local param1, param2 = arg[1], arg[2]
local register = io.popen("kakc query register 1"):read()
local text = register:gsub(param1, param2)
os.execute("kakc add-highlighter window/mycommand dynregex " .. text .. " 0:default,+u")

There are many informations in the above examples. Let’s start with the first one:

  • kakc subcommands are named after the commands they invoke;
  • a custom command is nothing more than an external executable (in this example, called mycommand).

When the new command is invoked (see the second example):

  • Kakoune executes the associated executable, setting some environment variables needed to identify the client and session from which the command was invoked;
  • whatever parameters are passed to :a-new-command are then passed to the executable as command line arguments (like luar currently does).

In the mycommand file:

  • parameters can be accessed as command line arguments;
  • Kakoune’s state is accessible via a new kakc query subcommand;
  • the plugin doesn’t need to manage session information; since everything is already set in environment variables, kakc itself can automatically read them, freeing plugin authors from handling them.

By doing so, both kakrc and command definitions would be opaque to Kakoune and, as such, all code related to parsing .kak files could be deleted from Kakoune, thus reducing the code base.

Is it enough? Or am I missing some complications? More importantly, is it feasible?

2 Likes