Can daemon clients use kitty?

Help
1

When daemonizing a session, clients can’t seem to use kitty at all?

Examples:

setsid kak -s test -d &

  • can join a client, no kitty commands loaded.

/usr/bin/env setsid kak -s test -d &

  • can join a client, kitty commands loaded

In both cases nothing happens when using:
:new, :repl-new, or :nop %sh{kitty @ set-tab-title test}

I briefly tried tmux as well, and had the same experience.

Should this work? Can it work?

2

It depends how kitty commands (like kitty @ set-tab-title) figure out which kitty process to connect to. I’m not familiar with kitty, but I am familiar with tmux, so I’ll talk about that.

When tmux starts up, it creates a Unix-domain socket in a private location in the filesystem. When tmux launches a shell inside itself, it sets the $TMUX environment variable to point at that socket. Since environment variables are inherited, any process the shell starts can read $TMUX and talk to the the tmux session it’s running inside of (that’s actually how Kakoune detects whether to load the tmux plugin at all). For example, let’s say you’re running Kakoune inside tmux:

tmux
 |
 +- kak

…and inside Kakoune (with the tmux plugin loaded) you run :new. That winds up running tmux new-window kak -c $kak_session so the new Kakoune client connects to the existing session. First Kakoune launches a new tmux process:

tmux
 |
 +- kak
     |
     +- tmux new-window kak -c 1234

The new tmux process checks $TMUX, connects to the session socket, and tells the session to launch a new window and run Kakoune inside it:

tmux
 |
 +- kak
 |
 +- kak -c 1234

However, if the original Kakoune session was started outside tmux, it won’t have the $TMUX environment variable, so there’s no way for :new to figure out what tmux session the new window should be created in.

You might like to think about it this way: imagine you start a Kakoune session as a daemon, then connect to it from a client running inside tmux, and another client running inside Kitty. Then a hook (without user interaction) tries to run :new - how can it know where the new client should be created?

1 Like
3

Thanks (again) for dropping some knowledge.
Exactly what I needed to point me in the right direction.

Kitty can communicate over a unix socket like tmux when configured.
And kakoune’s kitty rc’s for windowing and repl were recently updated to support this.

I added this to my kitty.conf:

allow_remote_control yes
listen_on unix:/tmp/mykitty

and all was good. Such a relief.

I was scripting some project setup, trying too many new things at once,
and have been struggling to understand all the pieces.

3 Likes
4

I am a kitty user, and I’m looking to take my Kak usage to the next level.

Have you done anything useful with kak + kitty yet?

I was inspired to look for forum posts about kitty by the cool tmux demo linked here Introducing kak-dap - an experimental Debug Adapter Protocol client for Kakoune

5

FWIW, that wasn’t meant to be a TMUX demo per se, but rather a demo for a plugin that requires multiple Kakoune clients to be laid out, hence the use of TMUX. Honestly, the only reason TMUX was used there was so Asciinema could record it - I usually use a Wezterm integration plugin.

Essentially, what was going on there was two additional Kakoune clients (for showing the stack trace and variable hierarchy) were being created, and another program (in this case the debuggee) was being spawned shortly afterwards. In this case, we used the tmux-terminal-vertical and tmux-terminal-horizontal commands Kakoune provides.

I don’t use Kitty myself, but my understanding is that it lays out its windows in a single tab much like a tiling window manager. So, depending on what layout you have set in your kitty.conf, you should be able to use invocations of the new command to spawn new Kakoune clients and terminal command to spawn additional programs, and achieve a similar effect.

2 Likes