Re: PATCH: Don't treat NUL as a combining character

[Mikael Magnusson <mikachu@gmail.com>]

On Sat, May 9, 2015 at 9:46 AM, Mikael Magnusson <mikachu@gmail.com> wrote:
> As title, if you input
> % something<ctrl-v ctrl-space>
> while combining_chars is set, it visually doesn't appear, but toggling
> the option makes it appear again (just like for actual combining
> characters).
>
> (I was momentarily confused why a command looking like *.mp4(e'fattr
> notes test') worked, then i remembered my ^_e bind to enter an e::
> glob uses ^@ as the separator. Normally I don't have combining_chars
> set, but this directory contains some NFD files.)
>
> I considered using L'\0' to clarify the intent, but I have no idea if
> all compilers support wchar literals?
>
> index 6b3cb97..13c053c 100644
> --- i/Src/zsh.h
> +++ w/Src/zsh.h
> @@ -2982,9 +2982,9 @@ typedef wint_t convchar_t;
>   * We can't be quite sure the wcwidth we've provided is entirely
>   * in agreement with the system's, so be extra safe.
>   */
> -#define IS_COMBINING(wc)       (WCWIDTH(wc) == 0 && !iswcntrl(wc))
> +#define IS_COMBINING(wc)       (wc != 0 && WCWIDTH(wc) == 0 && !iswcntrl(wc))
>  #else
> -#define IS_COMBINING(wc)       (WCWIDTH(wc) == 0)
> +#define IS_COMBINING(wc)       (wc != 0 && WCWIDTH(wc) == 0)
>  #endif
>  /*
>   * Test for the base of a combining character.

Instead of making this path ever so slightly slower by adding an extra
test that only matters a fraction of the time, could we actually make
it wc > 127 instead? I'm assuming unicode doesn't define anything in
ascii to be a combining character anyway, and then we would avoid the
wcwidth call in Most™ cases.

-- 
Mikael Magnusson