mirror of
https://github.com/neovim/neovim.git
synced 2026-07-11 03:49:41 +00:00
444d0b8b6c
Problem: Separation markers (%=) are ignored within item groups. This lead to a regression when the C implementation of the statusline was replaced with a default expression. When the user configured a custom ruler expression with a %= and used the overloaded item group syntax to set the ruler width, the separation marker worked in the ruler, but not when the ruler was incorporated into the statusline where the item group syntax was interpreted in the usual way. Solution: Analogously to top-level behaviour, expand separation markers evenly within item groups until `minwid` is reached (if set). ref https://github.com/neovim/neovim/pull/33036 fix https://github.com/neovim/neovim/issues/39984 ref https://github.com/neovim/neovim/issues/40247 Problem: The recursion offset into the static `stl_items` was not taken into account when adjusting the item count after truncation. Steps to reproduce: first prepare `stl_items`: set stl=%{%repeat('%#Error#',10)%} then watch how the Error highlight leaks into the recursive call: set stl=%l%l%l%{%nvim_eval_statusline('test%l%<',{'maxwidth':3,'highlights':1}).highlights%} ref https://github.com/neovim/neovim/issues/32259 * fix(statusline): consistent truncation at multicell character Problem 1: truncation of item groups at multicell character didn't take into account that minwid can be specified as a negative number. Problem 2: after truncation at top-level from the right at multicell character, the returned width was always `maxwidth`, even though the actual width was reduced. In vim, this can be observed as a statusline that is not fully drawn until the edge of the screen: vim --clean +"set ls=2 stl=%{%repeat('x',&columns-2)%}🙂x%<" Problem 3: after truncation at top-level from the left at multicell character, the resulting gap to reach `maxwidth` again was filled with fillchars, but then the final NUL was not set correctly. This can be seen in the following example, where the statuscolumn spills into the editing area starting from line 10: nvim --clean +"set number stc=%<x🙂%{repeat('x',43)}%l" +"norm yy10p" Solution: fix the small errors and, at top-level, consistently reduce the size instead of compensating with fillchars. In the case of the statusline and the winbar, the remaining place is filled with the configured fillchars in `win_redr_custom`, after `build_stl_str_hl` has returned. In all other cases (title, icon, statuscol, tabline, ruler), there seems to be no point in adding additional spaces at the end. * feat(statusline)!: scope %< to item groups Problem: Previously, item groups were only truncated at the beginning, which is often not desired. In the example %.15(path: %f%) the group's title/label is truncated away: <th/to/file.txt Truncation markers (%<) in item groups were processed at the top-level in the end, which can be confusing. Only the first %< is used for the whole string, and it is used even if the containing item group is hidden. Additionally, in the case of hidden item groups, the marker's position was not adapted. For example, %(hidden%<%)%f had the effect of truncating the path somewhere in the middle: /path/<file.txt Solution: Make truncation consistent with top-level behaviour, which has a better default of truncating at the first `Normal` item, i.e. path: <file.txt and allows for fine-grained control with truncation markers (%<). E.g. %.15(path: %f%<%) now yields path: /path/to> The original behaviour can be restored like so: %.15(%<path: %f%) BREAKING CHANGE: %< is no longer processed at top-level - the default truncation behaviour has changed: now at first item - truncation markers inside item groups don't affect truncation outside of the item group anymore - several truncation markers can now have an effect when separated with item groups, whereas previously only the first one globally had ref https://github.com/neovim/neovim/issues/39984