This version: (1) retains tmux support, and (2) retains the ability for users to control refocus based on buffer conditions -- e.g., filetype.
The env files don't get the $kak_opt_* variables unless they're passed in, so I still needed to modify the wrapper; as requested, instead of exporting in connect.kak in imports an env file that does the same thing, sort of.
I changed the logic from a confusing nested if to two separate cases. This has two effects:
It's easier to read
It collects all send commands into one place, as your code did
It's less efficient because it always evaluates at least 2 boolean expressions, and in half the cases, always evaluates 4.
It was necessary to retain the focus for tmux after the send command. The alternative would be to call send twice and use the nested ifs. Despite the unnecessary extra boolean tests, I prefer this version, and it's not in a loop so it probably doesn't matter much.
I don't know git well enough to rebase this cleanly into a single commit, while retaining the merge from your master. Sorry about that.
I prefer connect to not know about i3 and tmux, but use the focus command implementation from x11.kak, tmux.kak, etc.
You can avoid exporting variables and get a value from a connected client with get '%opt{connect_focus}' from a connected terminal / shell, so that the value is live and not static.
This version: (1) retains
tmux
support, and (2) retains the ability for users to control refocus based on buffer conditions -- e.g.,filetype
.The env files don't get the
$kak_opt_*
variables unless they're passed in, so I still needed to modify the wrapper; as requested, instead of exporting inconnect.kak
in imports an env file that does the same thing, sort of.I changed the logic from a confusing nested
if
to two separate cases. This has two effects:send
commands into one place, as your code didIt was necessary to retain the focus for tmux after the
send
command. The alternative would be to callsend
twice and use the nestedif
s. Despite the unnecessary extra boolean tests, I prefer this version, and it's not in a loop so it probably doesn't matter much.I don't know git well enough to rebase this cleanly into a single commit, while retaining the merge from your master. Sorry about that.