Hard dividers (for segments with different background colors) are now
always drawn, regardless of the draw_divider option, because it looks
horrible when segments with different bg colors don't have a divider
between them.
This resolves an issue with the filename and modified flag
in the default theme where the filename segment had to set the
draw_divider flag based on the contents of the modified flag to be
rendered correctly.
Another rendering pass is necessary before calculating the filler
segment's lengths, because center segments may lose their separators
after removing low-priority segments.
Some unicode and variable assignment issues has been resolved so
everything renders correctly.
This change removes the Segment class as this takes forever to remove
from the segment array when removing low-priority segments. It has
instead been replaced by a wrapper function that works the same and
returns a working dict of all segment properties.
The regex substitution bottleneck in the vim example has been fixed by
using a single-character percent placeholder in vim segments which is
later replaced with a double percent using str.replace().
This commit almost doubles the segment rendering performance. This is
accomplished by caching a lot of data like highlighting groups, moving
some calculations out of loops, and by performing less function calls
overall.
When a width is specified the main speed improvement comes from avoiding
rendering the raw segments over and over until the statusline is short
enough. Instead, the raw rendering is stored as a segment property and
the combined length of all these renderings is used when removing
low-priority segments instead. This results in a maximum of two
rendering passes.
Some "less pythonic" solutions have been chosen some places for
performance reasons, e.g. joining strings instead of appending and
joining lists.
Overall this commit appears to make the performance equal or better than
the legacy vimscript implementation. Later optimizations (in particular
finding another method than remove() for removing low-priority segments)
may make this version of Powerline far superior both in terms of
functionality and performance.
This commit introduces a bunch of changes. Most importantly, it ensures
that split windows and inactive windows work as expected. This is
accomplished with some clever workarounds for vim's statusline
limitations.
Vim statuslines evaluated using the %! statusline item are always
evaluated in the buffer context and not in the statusline's owner
window's context, and this made the previous implementation show the
same statusline for all windows. The only way to ensure that the correct
statusline is rendered to the correct window is to walk through all
windows, and setting the statuslines with a reference to the current
window number every time the current window is changed. This is
accomplished by a set of BufEnter, BufLeave, etc. autocommands.
The Syntastic segment has been temporarily removed due to errors when
referencing the statusline function before Syntastic has been loaded.
When more than one filler segment is specified it may sometimes be
a remainder when calculating the amount of whitespace. divmod() is used
to retrieve the remainder, which is added as whitespace to the first
filler segment.
The examples have been moved into their own directory. The vim example
now uses pyeval() and vim.bindeval() and loads the Python file through
an import (so it gets compiled) for speed improvements.
The segment tree seemed like a good idea at the time, but for the core
code it's probably best to do a single-dimensional array and instead
have some duplicated data (common segment attributes). By removing the
tree structured segments the code is much simpler to understand and use,
and probably quite a bit faster.
If a tree structure is wanted for ease of configuration, it could easily
be supported in the JSON config files for vim statuslines, and then
letting the vim statusline code flatten the configuration into
a single-dimensional array for rendering.
Powerline will probably only be Python 2 in the foreseeable future
because of poor Python 3 support in applications like vim, so this
small change ensures correct unicode behavior in Python 2.
The padding argument has been removed and is now handled automatically.
Segments without dividers are not padded anymore.
This was necessary to ensure that segments are rendered correctly when
cropping segments (overriding the padding argument screwed up the
padding for segments without dividers and without padding).
This example only does a single type of highlighting (normal mode) but
demonstrates nicely how rendering a statusline with Python could work.
This also utilizes the new width functionality to crop away less
important segment if the window is too small, and do the padding with
Python instead of using vim's split segment.
Some optimization will probably be necessary, as calling Python for each
statusline redraw is quite expensive. A solution could be evaluating the
segments in Python once and then calculating the width and crop away/pad
the segments, and then sending the statusline with unevaluated segments
to vim for rendering without calling Python. Only some events (like
CursorHold, InsertEnter/InsertLeave, etc.) would trigger a re-render
with Python, a recalculation of the width and cropping/padding.
The Segment class has been given two new properties: priority and
filler. The render method has been given a width argument.
If the width argument is specified when rendering a segment and the
rendered segments are too wide, segments are dropped in order of
priority, with the lowest priority (highest number) being dropped first
and any segment with priority < 0 is kept, regardless of the specified
width.
If the width argument is specified along with one or more filler
segments, the filler segments will pad the remaining space with space
characters until the desired width has been reached.
The handling of segment attributes has also been improved by lazily
looking up the correct attributes in the segment tree when it's being
rendered.
Finally, the rendering code itself has been improved a bit with less
code duplication and much more readable code.
This commit also includes a basic proof-of-concept demo for creating vim
statuslines. When creating vim statuslines you basically need to first
create the statusline the same way as the terminal demo, use the vim
renderer and then afterwards loop through the collected highlight groups
in the vim renderer and write those as vim highlight statements.
Vim obviously needs a ton of wrapper code to make everything work
properly (separate modes, callbacks, all that stuff) so the current demo
only shows some basic statusline highlighting.
This change joins the fg/bg/attr methods into a single hl method in the
renderers. This provides the same functionality, and it simplifies the
terminal rendering by being able to join all the attributes into one
escape sequence.
It's also a necessary change for the vim renderer, as this renderer
needs to log all the highlighting and create separate highlighting
classes for every single color and attribute combination. The only way
to do this is to have a single highlighting method.
This is currently rendered with the terminal renderer, and is just
a simple proof-of-concept of how vim statuslines can be defined with the
Python API.
Kim Silkebækken
ZyX