Use a feature of tmux v1.8+ to change the FG color of the last active
window to blue. This uses the foo-{attr,bg,fg} format, which is
deprecated (although still available) starting with tmux v1.9 in favor
of the corresponding foo-style variable. However, tmux v1.9 is not yet
ubiquitous enough to move to the foo-style variables. For example, the
latest Ubuntu LTS (14.04) only has tmux v1.8 available in its
repositories, so the foo-{attr,bg,fg} variables prove to be more
'compatible' for now.
For future reference, here is the modification that should be made once
tmux v1.8 is deemed old enough to drop support for (or whenever the
deprecated foo-{attr,bg,fg} variables go away in the latest version of
tmux):
-set -g window-status-last-fg colour31
+set -g window-status-last-style fg=colour31
It might be appropriate to add version checking around some of these
types of options for maximum compatibility, but my initial attempt to
explore version checking in the tmux config file got extremely messy in
a hurry.
This modification to the tmux powerline binding allows the user to
easily identify when the prefix has been sent. When the prefix has
been sent, the session block changes from white to blue (matching the
color of the active window). This is accomplished using the conditional
functionality of tmux format strings and the 'client_prefix' format
variable. Unfortunately, the tmux parser fails to properly parse out
comma-separated format strings inside a format conditional, so those
have been split out into individual segments as well. Attempting to
re-combine the formats inside the conditionals will break this feature.
Reason: tmux may be launched and $TMUX set, but current shell still not under
tmux (and most likely there are no active session). In this case `tmux refresh
-S` may fail with “no clients” message, which is annoying.
It seems that old fix for old code is no longer needed. At least I do not see
any problems with
vim -u NONE -S ~/.vam/powerline/powerline/bindings/vim/plugin/powerline.vim --cmd 'set ls=2'
.
Fixes#250
Reason: $? may be overridden by the previous commands in PROMPT_COMMAND that do
not keep it like _powerline_prompt does (see `return $last_exit_code`).
(@ascrane)
Closes#836
Reason: otherwise it is likely that two updating processes are being run
simultaneously. With the current code it is not impossible as well, but less
likely.
Note: to make prompt fancy enough powerline-daemon should be used. Otherwise
continuation prompt length is different from what was expected:
With daemon:
user > env > path > if true ; then
then > fi
Without:
user > env > path > if true ; then
then > fi
Fixes#771 as I do not want to touch tcsh any longer
Austin Beam
ZyX
Kjell Braden