Assuming powerline was working before update and stopped only after there are two possible explanations:
In the second case you, of course, should report the bug to powerline bug tracker. In the first you should make sure you either have only one powerline installation or you update all of them simultaneously (beware that in the second case you are not supported). To diagnose this problem you may do the following:
If this problem is observed within the shell make sure that
python -c 'import powerline; print (powerline.__file__)'
which should report something like /usr/lib64/python2.7/site-packages/powerline/__init__.pyc (if powerline is installed system-wide) or /home/USER/.../powerline/__init__.pyc (if powerline was cloned somewhere, e.g. in /home/USER/.vim/bundle/powerline) reports the same location you use to source in your shell configuration: in first case it should be some location in /usr (e.g. /usr/share/zsh/site-contrib/powerline.zsh), in the second it should be something like /home/USER/.../powerline/bindings/zsh/powerline.zsh. If this is true it may be a powerline bug, but if locations do not match you should not report the bug until you observe it on configuration where locations do match.
If this problem is observed specifically within bash make sure that you clean $POWERLINE_COMMAND and $PROMPT_COMMAND environment variables on startup or, at least, that it was cleaned after update. While different $POWERLINE_COMMAND variable should not cause any troubles most of time (and when it will cause troubles are rather trivial) spoiled $PROMPT_COMMAND may lead to strange error messages or absense of exit code reporting.
These are the sources which may keep outdated environment variables:
If this problem is observed within the vim instance you should check out the output of the following Ex mode commands
python import powerline as pl ; print (pl.__file__)
python3 import powerline as pl ; print (pl.__file__)
One (but not both) of them will most likely error out, this is OK. The same rules apply as in the 1), but in place of sourcing you should seek for the place where you modify runtimepath vim option. If you install powerline using VAM then no explicit modifications of runtimpath were performed in your vimrc (runtimepath is modified by VAM in this case), but powerline will be placed in plugin_root_dir/powerline where {plugin_root_dir} is stored in VAM settings dictionary: do echo g:vim_addon_manager.plugin_root_dir.
There is a hint if you want to place powerline repository somewhere, but still make powerline package importable anywhere: use
pip install --user --editable path/to/powerline
If you are using pip based installation do not forget to add pip-specific executable path to $PATH environment variable. This path usually looks something like $HOME/.local/bin (linux) or $HOME/Library/Python/{python_version}/bin (OS X). One may check out where powerline-config script was installed by using pip show -f powerline-status | grep powerline-config (does not always work).
To get rid of these lags there currently are two options:
This is exactly why powerline has official mksh support, but not official ksh support. If you know the solution feel free to share it in powerline bug tracker.
This happens because z is launching some jobs in the background from $POWERLINE_COMMAND and these jobs fail to finish before powerline prompt is run.
Solution to this problem is simple: be sure that z.sh is sourced strictly after powerline/bindings/bash/powerline.sh. This way background jobs are spawned by z after powerline has done its job.
If your locale encoding is not unicode (any encoding that starts with “utf” or “ucs” will work, case is ignored) powerline falls back to ascii-only theme. You should set up your system to use unicode locale or forget about powerline fancy characters.
Make sure that, whatever urxvt package you’re installing, both the unicode3 and frills features are enabled at compile time. Run urxvt --help 2>&1 | grep options: to get a list of enabled options. This should contain at least frills, unicode3 and optionally iso14755 if you want to input Unicode characters as well.
Compiler flags example:
–enable-frills –enable-unicode3
As long as your terminal emulator is compiled without unicode rendering, no amount of configuration will make it display unicode characters. They’re being considered ‘unnecessary features’, but they add negligible overhead to the size of the installed package (~100KB).
You need to configure the fillchars setting to disable statusline fillchars (see :h 'fillchars' for details). Add this to your vimrc to solve this issue:
set fillchars+=stl:\ ,stlnc:\
If your vimrc has something like
autocmd! BufWritePost ~/.vimrc :source ~/.vimrc
used to automatically source vimrc after saving it then you must add nested after pattern (vimrc in this case):
autocmd! BufWritePost ~/.vimrc nested :source ~/.vimrc
. Alternatively move :colorscheme command out of the vimrc to the file which will not be automatically resourced.
Observed problem is that when you use :colorscheme command existing highlighting groups are usually cleared, including those defined by powerline. To workaround this issue powerline hooks Colorscheme event, but when you source vimrc with BufWritePost (or any other) event, but without nested this event is not launched. See also autocmd-nested Vim documentation.
It may be one of the incarnations of the above issue: specifically minibufexpl is known to trigger it. If you are using minibufexplorer you should set
let g:miniBufExplForceSyntaxEnable = 1
variable so that this issue is not triggered. Complete explanation:
Note
This setting was introduced in version 6.3.1 of minibufexpl and removed in version 6.5.0 of its successor minibufexplorer. It is highly advised to use the latter because minibufexpl was last updated late in 2004.