Should be faster with new interfaces, but that is not the case
Should remove zero that can be viewed temporary in place of statusline in new
windows
Target: ressurect setup function like source_plugin (but in place of sourcing
something code is moved to python) to make it possible to do the following
sequence:
1. Install powerline via pip
2. Add a line to the vimrc like
py from powerline.vim import setup as setup_powerline; setup_powerline(); del setup_powerline
3. See new fancy statusline
Currently there are no convenient options to use powerline installed by pip in
vim. powerline/bindings/vim/plugin/powerline.vim will do what it does: check for
appropriate python versions available, fix sys.path and so on, but it won’t
create autocommands, set options or define PowerlinePyeval function.
Note: may be rebased on top of the develop.
For PangoMarkup it is pretty useless currently (segment_info does not contain
anything useful).
Note: this does its job by replacing default behavior.
Source of issue: previous default used either segment_info argument (containing
{"args": args, "environ": os.environ}) or default segment_info, shell renderer
merged default segment_info with .render() argument. Now segment_info is merged
by default and old behavior moved to vim renderer which is the only one that is
designed to use this.
Fixes#391
No need to bother both developers (that need to create class names compatible
with file name, which is not obvious if not looking into main Powerline class)
and computer (that needs to recompute class name each time) if it is possible to
bother only developers (or only computer, but this contributes to higher startup
times).
About not obvious: when you look into zsh_prompt.py and see only
ZshPromptRenderer name you only think that powerline upstream is following
strict code style. You don’t think there is a technical reason for such naming,
like you don’t think there is technical reason for having blank lines. When you
look into zsh_prompt.py and see `renderer = ZshPromptRenderer` it is obvious
that there is technical reason for writing code this way because new variable is
never used in the module itself.
In any case for all other extensions they are useless. (Except for ipython, but
it is TODO and I am not going to use matchers this way, simple dictionary
lookup is better in this case.)
Removed autocommands as well. Powerline() function is now responsible both for
displaying powerline and for updating statuslines. No cmdwin events not
triggered workaround nonsense anymore.
Fixes#237Fixes#236Fixes#222Fixes#232
API changes done:
- memoize additional_key function now accepts all function arguments
- get_theme now receives matcher_info
- render now receives segment_info and matcher_info, but segments and themes
were removed
- due to very different ways of obtaining column information col_current
splitted back to col_current and virtcol_current. The former should be false
in case of horizontal scrollbind (when &scrollopt contains hor)
- added requires_segment_info decorator for convenience
Other changes:
- removed all vim function calls that were possible to remove
- removed direct vim.eval calls
This is faster then super() calls and also more convenient.
Fixes#142 just as well
Conflicts:
powerline/renderers/bash_prompt.py
powerline/renderers/ipython.py
powerline/renderers/shell.py
powerline/renderers/zsh_prompt.py
What does hl() mean? It looks like “highlight an empty string”, but is actually
“reset highlight style”. In addition if you are writing “hl()” function for new
renderer you need to care about “contents” variable (in two places!: None for
super() call and (contents or u'') after super() call) though function is
actually doing nothing with it. It is just inconvenient.
This commit introduces the following changes to themes and segment
rendering:
- Spacer segments are now regular string/function type segments with
"width": "auto" in the themes.
- The "rjust"/"ljust" properties have been replaced by the "width"
option combined with a new "align" option.
- Renderer._render_segments() is now a generator which renders each
segment separately, and assigns the rendered contents to
"_rendered_hl" and "_rendered_raw" in the segment dict.
- Renderer.render() returns the segments by joining the "_rendered_hl"
values for each segment.
- Spacer segment widths are calculated in the render() method, and
assigned to "_space_left" and "_space_right" in the segment dict.
These spaces are then applied in Renderer._render_segments().
- All space characters are converted to no-break spaces (U+00A0) in the
"_rendered_hl" property.
Refs #113.
Refs #154.
Awesome WM uses the Pango Text Attribute Markup Language
(http://developer.gnome.org/pango/stable/PangoMarkupFormat.html), and
since other applications and window managers may use the same markup
language it's better to have a common renderer for this markup language.
This allows the hl() methods to wrap highlighting code *around* the
segment contents, this is required for e.g. Pango markup in Awesome
statuslines (segments must be wrapped in <span ...>...</span> tags).
ZyX
Kim Silkebækken
