Re: zsh/complist colours improperly handle multibyte characters

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Oct 21, 12:09pm, Danielle McLean wrote:
}
} 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.

Reaching this conclusion might be understandable, but it is pretty far
off the mark.

The problem with the (#b) example is not that the pattern has matched
improperly, but that #ifdef MULTIBYTE_SUPPORT has never been worked
into complist.c:clprintfmt().  So it is counting the bytes rather than
the display width when deciding where to start/stop coloring.

I'm not going to dive into that, I don't know the multibyte handling
code well enough.

The problem with the vertical-bar example is that the pattern did not
compile correctly at all.  The same effect occurs if you use "#" in
that position -- it results in an invalid pattern which is silently
ignored.

Stepping through with gdb for the vertical-bar pattern, I get:

 pattern.c:1530: BUG: - missing from numeric glob

I thought this was a metafication problem, and indeed if I metafy()
the string passed to patcompile() then the compilation succeeds, but
then the resulting program fails to match for even simple patterns
so nothing is ever colored.

This is about as far as I'm going to be able to get with this.