fix: don't crash when list-colors zstyle isn't dircolors-shaped#384
fix: don't crash when list-colors zstyle isn't dircolors-shaped#384pdehlke wants to merge 1 commit into
Conversation
-z4h-set-list-colors assumed the list-colors style always holds
simple GNU dircolors "code=value" pairs. Third-party completion
tools (e.g. carapace) can set list-colors themselves using zsh's
richer match-highlight syntax (multiple `=`-separated fields per
entry), which splits into an odd number of fields here. Building
the associative arrays directly from that odd-length list is a
fatal error ("bad set of key/value pairs for associative array")
that aborts the whole completion widget, not just this function.
Validate the split lists have even length before building the
associative arrays, and bail out (skip colorization for this
value) the same way the function already does when no list-colors
style is set at all.
|
Do you have an example? Do we need to split only on the first =? |
|
carapace itself is a little peculiar: the output it emits for a specific invocation depends on how many match-highlight entries carapace emits and how many capture groups each has, which shifts with the match set and even the terminal width. So for example, on MacOS: In this particular case the three colon-separated entries happen to add up even, so this exact invocation doesn't cause an abort, but you can see the odd numbered fragment shapes there. Crashing is match-set dependent, not deterministic on every tab completion. You're much, much smarter about zsh than I am, but here's my thinking about splitting only on the first =: Splitting on just the first = would stop the crash, but the resulting entry (key = a glob pattern like (#b)(Users/), value = 0=38;2;148;226;213) still couldn't be used — nothing in z4h matches filenames against that pattern. As far as I peronally can tell, it would just trade a crash for a harmless dead entry. Again as far as I can tell, z4h's colorizer doesn't support pattern-based list-colors entries at all, only literal filename/extension ones. Bailing out when the shape doesn't fit seems like the right thing to do. |
|
If z4h understands only a specific format of this setting, perhaps we should check whether the setting is in that format? |
2 participants
-z4h-set-list-colors assumed the list-colors style always holds simple GNU dircolors "code=value" pairs. Third-party completion tools (e.g. carapace) can set list-colors themselves using zsh's richer match-highlight syntax (multiple
=-separated fields per entry), which splits into an odd number of fields here. Building the associative arrays directly from that odd-length list is a fatal error ("bad set of key/value pairs for associative array") that aborts the whole completion widget, not just this function.Validate the split lists have even length before building the associative arrays, and bail out (skip colorization for this value) the same way the function already does when no list-colors style is set at all.