There's no visibile difference between two focused/unfocused clients in Tmux panes

[lenormf]

Feature

A client that lacks focus in a Tmux pane shows no indication of that.

HTH.

[Screwtapello]

I feel like it's more tmux's job to show which pane is focussed, rather than Kakoune's job.

[lenormf]

The issue is that clients show no indication that they are not accepting input, irrespective of what window manager they're in. If anything can be done to make a step towards that, I'll take it, I don't know what though (a modeline token?).

Several users have mentioned some kind of visual effect on the main cursor, but I don't think that's appropriate.

Alternatively we could come up with a snippet that implements that for given window managers and document it in the wiki, if that hasn't been done already. If there's no need for a core feature to implement that, I'll close this issue, just want to leave no doors un-opened.

[vbauerster]

I have following snippet in my config, which toggles status line background. It works most of the time, but has some edge cases which I don't remember right now.

hook global FocusIn .* %{
    unset-face window StatusLine
    evaluate-commands %sh{
        base00="rgb:FDFDFD"
        base03="rgb:8e908c"
        for client in $kak_client_list; do
            if [ "$client" != "$kak_hook_param" ]; then
                printf 'eval -no-hooks -client %s %%{face window StatusLine %s,%s}\n' \
                "$client" "$base00" "$base03"
            fi
        done
    }
}

hook global WinDisplay .* %{
    unset-face window StatusLine
}

Updated script is on wiki.

[toddyamakawa]

tmux can definitely handle this.

tmux set-option -g active-border-style "formathere"
tmux set-window-option -g pane-border-format "formatgoeshere"

[krobelus]

For the lazy, here's an example ~/.tmux.conf with green borders:

set -g pane-border-style			"fg=colour238 bg=default"
set -g pane-active-border-style 		"fg=green bg=default"

[mawww]

I dont think thats something we can reliably fix in Kakoune, a client always accept inputs, its up to the terminal emulator to send it or not. The FocusIn/FocusOut events can help make an educated guess, but there no guarantee that they will be emitted by the terminal emulator nor that there will be a single focused client as we can have clients running in many different terminals at the same time (some from ssh, some in tmux, some in wayland, some through X11...).

Having a hook based best-effort solution seems like the best bet, as it does not then need to be correct, it just need to work well enough for the users workflow.

[lenormf]

That's fine, case closed!