This commit refactors `TestVim` test class in test_configuration so that
1. `test_environ_update` does not leave state (value of `powerline_config_paths`
global Vim variable) behind other tests can use.
2. `test_local_themes` does not rely on state left from `test_environ_update`,
instead using new facility for providing needed value of
`Powerline.get_config_paths` call. This facility will be used later in BAR
tests.
Ref #1256
Reasoning:
1. vt* TERMs (used to be vt100 here) make tmux-1.9 use different and identical
colors for inactive windows. This is not like tmux-1.6: foreground color is
different from separator color and equal to (0, 102, 153) for some reason
(separator has correct color). tmux-1.8 is fine, so are older versions
(though tmux-1.6 and tmux-1.7 do not have highlighting for previously active
window) and my system tmux-1.9a.
2. screen, xterm and some other non-256color terminals both have the same issue
and make libvterm emit complains like `Unhandled CSI SGR 3231`.
3. screen-256color, xterm-256color and other -256color terminals make libvterm
emit complains about unhandled escapes to stderr.
4. `st-256color` does not have any of the above problems, but it may be not
present on the target system because it is installed with x11-terms/st and
not with sys-libs/ncurses.
For the given reasons decision was made: to fix tmux-1.9 tests and not make
libvterm emit any data to stderr st-256color $TERM should be used, up until
libvterm has its own terminfo database entry (if it ever will). To make sure
that relevant terminfo entry is present on the target system it should be
distributed with powerline test package. To make distribution not require
modifying anything outside of powerline test directory TERMINFO variable is set.
It appears that tmux-1.6 is not able to function properly. Most likely this is
because prior to some tmux version running shell commands in background is the
default and only option and starting from some version `run-shell` does not run
processes in background *by default*.
This means that `source` action is run while `setenv` action is running and
since `source` needs to load a bunch of configuration files, *including*
importing a bunch of modules when creating renderer `source` and corresponding
tmux actions are finished earlier.
It is only a guess though: I am not even seeing race condition: `source` *is*
run, `setenv` also *is*, but `source` is *always* before `setenv`.
ZyX
S0lll0s
Michael Snead