zsh/complist colours improperly handle multibyte characters

[Danielle McLean <gopsychonauts@xxxxxxxxx>]

Although zsh patterns usually have full support for multibyte characters, a zsh pattern containing certain multibyte characters will fail to match if provided to zsh/complist using $ZLS_COLORS or the list-colors zstyle. For example, the following zstyles will fail to match and colour anything:

    zstyle :completion:*:options list-separator │
    zstyle :completion:*:options =*│*=32
    ls -l<TAB>		

This is not the case for *all* multibyte characters. For example, the following zstyles successfully colour the entire option green:

    zstyle :completion:*:options list-separator ©
    zstyle :completion:*:options =*©*=32
    ls -l<TAB>

Additionally, when applying multiple colours with a (#b) pattern, multibyte characters break the colouring even if matched with a wildcard like * rather than a literal. In this example, the options are blue and their descriptions green - except for the last two characters of the description which are not coloured:

    zstyle :completion:*:options list-separator │
    zstyle :completion:*:options "=(#b)([^ ]#)(*)=0=34=32"
    ls -l<TAB>

This issue also occurs if © is used as the separator: the complist will colour all but the last character of the description, in that case.

I believe the reason behind this behaviour is that in UTF-8, © is a two-byte character and │ is a three-byte character. Presumably, zsh/complist's pattern parsing is only aware of one- and two-byte chars, and its (#b)-based grouping mistakenly assumes that all characters are single bytes.