[REQUEST] a way to write data to stdout when connecting to an existing session

[silversquirl]

Feature

Currently it's very annoying to get data out of a kakoune session remotely. The best I could come up with is something like this:

tmp_dir="$(mktemp -d)"
fifo_path="$tmp_dir/fifo"
mkfifo "$fifo_path"
kak -p "$session" <<EOF
echo -to-file $fifo_path %val{buflist}
EOF
buflist="$(cat "$fifo_path")"
rm -rf "$tmp_dir"

That's a lot to simply get the value of %val{buflist} into a shell variable.

There are a couple of possible solutions:

1. Make -f work together with -c. This would allow doing something like buflist="$(kak -c "$session" -f ':reg dquote %val{buflist}<ret><a-p>a<ret>' </dev/null)" instead of the above (dependent on #4879 being fixed). Note that this has a slightly different output format compared to the above, as it's line-separated rather than NUL-separated.
2. Allow -p to write to stdout. The simplest option here is probably having -p open an empty scratch buffer and write its contents to stdout when stdin is closed.

Usecase

This is useful for writing scripts that remotely interact with kakoune. For example, I recently wrote a small Python script that had to run a command in every kakoune session on the machine and read back a value.

[Screwtapello]

For reference, tools like kakoune-remote-control work the same way:

https://github.com/danr/kakoune-remote-control/blob/0eb79e46fdd126346b3d9e71e93b9c5834feb5f7/krc#L125-L132

It'd be nice if kak -p were effectively a simple client that sent stdin as commands, and printed :echo output to stdout. Unfortunately, Kakoune's client-server protocol doesn't communicate :echo output separately, it sends all the text that would be displayed on-screen by a terminal client, which is presumably why it works the way it currently does.

It would be nearly as nice if Kakoune had some built-in implementation of the "make temp file, tell server to echo to temp file, read temp file, delete temp file" dance.

Kakoune is designed to integrate with other Unix tools, but it's a lot more comfortable if it's orchestrating the interaction, rather than letting other things interact with it.

[mawww]

This is definitely a pain point that needs to be solved. An third alternative solution would be to extend the command/response fifo system to allow long-lived ones, which would reduce the example to:

echo "echo -to-file $kak_response_fifo %val{buflist}" > $kak_command_fifo
buflist=$(cat $kak_response_fifo)

This could be slightly improved by keeping a map of command to response fifo in Kakoune:

echo "echo -to-response-fifo %val{buflist}" > $kak_command_fifo
buflist=$(cat $kak_response_fifo)

I do like the idea of outputing whatever is echo'd from kak -p however it can lead to some ambiguity: echo "eval -client foo %{ echo %val{selections} }" | kak -p. I guess we could add yet another switch to echo to control that.

We could also introduce a `kak -expand ', but that would lose much of the flexibility of using arbitrary commands to get to the correct state/context.

[Screwtapello]

I do like the idea of outputing whatever is echo'd from kak -p however it can lead to some ambiguity: echo "eval -client foo %{ echo %val{selections} }" | kak -p.

That ambiguity already exists with :fail:

printf "%s" "eval -client client %{ fail blah }" | kak -p session

kak -p does not show the failure message and does not exit with a non-zero exit code, the intended client does not show the failure message, it only winds up in the *debug* buffer. Of course, sending fail blah directly to kak -p has exactly the same result so in that sense at least it's consistent.

[gknittl]

Perhaps a /proc like virtual file system e.g. bufflist=$(cat /kak/$systemid/$clientid/buflist/quoted)

[Delapouite]

@gknittl see https://github.com/mawww/kakoune/issues/1609#issuecomment-366425915