Use $kak_command_fifo for more efficient scrolling

[Screwtapello]

Currently, the plugin works by launching a bunch of kak -p processes (in the shell fallback) or connecting directly to Kakoune's control socket (in the Python script) to inject a bunch of vj and vk keystrokes. Now that Kakoune asynchronously accepts commands from scripts via $kak_command_fifo, we should try it out and see if it's more efficient.

[Screwtapello]

It turns out it doesn't actually work - you can printf 'exec vj' > "$kak_command_fifo" all you like, but Kakoune doesn't actually repaint the screen until the shell block exits. As a result, this plugin still needs to use kak -p (or direct socket connections).

[caksoylar]

Hi @Screwtapello, thanks for bringing it up! I actually experimented with this a bit when the feature first came out, then ran into some issues which we had discussed a bit around https://discord.com/channels/717163870724161556/717165513750609991/857003103127470130.

I tried it again and at least that specific issue doesn't exist anymore; maybe it was fixed in mawww/kakoune@19e2225.

There is still a couple other issues I had encountered though, one of which you noticed:

1. Kakoune waits until shell block is done to scroll
2. We can no longer background the scrolling process since we are directing output to the fifo

In my limited recent experimenting 1. seems solvable by manually redrawing with <c-l>, e.g. this snippet works as expected to scroll 50 lines one by one:

nop %sh{
    python3 -c 'import sys, time
fifo = sys.argv[1]

for i in range(50):
    with open(fifo, "w") as cf:
        cf.write(f"exec jvj<c-l>")
    time.sleep(0.1)
' "$kak_command_fifo"  # >/dev/null 2>&1 </dev/null &
}

Issue 2. is not as critical but it helps us be more responsive to user input, since the user can cancel an in-progress scroll by doing something else. But it can be argued that it is better if something goes wrong since you can <c-c> the process to kill it. (It can also be distracting since you sometimes get flashes of "Waiting for shell command to finish" in the statusline.)

Overall I think it might be worth experimenting with to see if we can live with not backgrounding the process, and also see if there are other rough edges in the fifo implementation we might run into. We can then consider pros and cons of either implementation.

[Screwtapello]

There were a couple of reasons I decided to play with $kak_command_fifo:

• I wanted to find out how annoying synchronous scrolling would be
• as you point out, it means you can cancel the in-progress scroll with <c-c>
• it would guarantee that hitting "i" during a scroll wouldn't fill your buffer with jvj (that hasn't happened to me recently, since I think the plugin takes steps to avoid it, but this would be a simpler way to avoid it)
• $kak_response_fifo can be used to keep the scroll engine in sync with Kakoune, instead of spraying key events and hoping they execute with about the right speed

When I hit the "Kakoune doesn't repaint until the shell block ends" issue, I deleted my experiment in progress, but now that you've pointed out <c-l> maybe it's worth trying again.