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