* feature/unicode-symbols: Update vim docs Add simple Unicode version of symbols. Closes #10.
…ode-symbols * yacoob/plain-unicode: Add simple Unicode version of symbols.
FontForge fails to generate valid PCF fonts, so pure bitmap fonts will need to be saved as BDF fonts. They may optionally be converted to PCF fonts at a later point using `bdftopcf`, but this is usually not necessary. TrueType fonts with or without bitmaps will always be stored as OTF fonts. This may later be updated to be configurable via a command-line switch. This commit also changes how the output filename is generated. Only the filename of the original font up to the first period is used, and `-Powerline.[format]` is appended to this filename. Closes #9.
This solves an issue where the statusline didn't get updated after closing the Command-T buffer. I'm not sure why the BufEnter or WinEnter autocommands aren't triggered when the cursor enters the previous buffer after closing Command-T, but it seems that the BufUnload event is triggered which solves this issue.
Although probably a rare case, sometimes one might have several powerline theme files with the same name (or simply symlinks) lying around in Vim's runtimepath. When that happens, filereadable() would return 'false', hence skipping the `source' process. This patch chooses the first path as the `main_path' for sourcing. It should also work in the normal case where only one path is returned from globpath().
`Stl_GetSyntaxErrors()` triggered some errors if `g:syntastic_stl_format` didn't exist. This may have been caused in some configurations where Syntastic loaded slowly or after Powerline. This function now checks if `g:syntastic_stl_format` exists, and returns an empty segment if it doesn't. It's possible that this commit also fixes #3. Closes #6.
This is an update which later will allow us to create statuslines for any of vim's modes (see ':help mode()' for details). This is accomplished by executing a function (Pl#GetStatusline()) in every statusline (mode() only returns the correct mode when being executed from the statusline). This update may also make it possible to dynamically generate the correct highlighting groups for each segment divider and thereby resolve the issue with incorrect highlighting for the divider between optional segments surrounded by two segments with different background color.
Cleared hl groups will now be recreated properly when changing the color scheme. When the ColorScheme autocmd was called, the hl groups wouldn't be recreated because s:CreateHiGroup() only ran hlexists() to check if a hl group existed. Cleared hl groups still exist even though they don't have any highlighting properties, so a helper function has been created which checks if the hl group exists AND if it's cleared or not.