PATCH: Don't treat NUL as a combining character

PATCH: Don't treat NUL as a combining character

[Mikael Magnusson]

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.


-- 
Mikael Magnusson

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

[Mikael Magnusson]

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

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

[Bart Schaefer]

On May 10,  2:02am, Mikael Magnusson wrote:
} Subject: Re: PATCH: Don't treat NUL as a combining character
}
} > -#define IS_COMBINING(wc)       (WCWIDTH(wc) == 0 && !iswcntrl(wc))
} > +#define IS_COMBINING(wc)       (wc != 0 && WCWIDTH(wc) == 0 && !iswcntrl(wc))
} 
} Instead of making this path ever so slightly slower by adding an extra
} test that only matters a fraction of the time

I think the test would be no slower (or at least faster than what you have
there) if you just put the wc != 0 as the last branch of the && chain?

} could we actually make it wc > 127 instead?

I don't know the definitive answer to that, but it seems it should also go
at the end.  We're really micro-optimizing here, though.

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

[Mikael Magnusson]

On Sun, May 10, 2015 at 2:14 AM, Bart Schaefer
<schaefer@brasslantern.com> wrote:
> On May 10,  2:02am, Mikael Magnusson wrote:
> } Subject: Re: PATCH: Don't treat NUL as a combining character
> }
> } > -#define IS_COMBINING(wc)       (WCWIDTH(wc) == 0 && !iswcntrl(wc))
> } > +#define IS_COMBINING(wc)       (wc != 0 && WCWIDTH(wc) == 0 && !iswcntrl(wc))
> }
> } Instead of making this path ever so slightly slower by adding an extra
> } test that only matters a fraction of the time
>
> I think the test would be no slower (or at least faster than what you have
> there) if you just put the wc != 0 as the last branch of the && chain?
>
> } could we actually make it wc > 127 instead?
>
> I don't know the definitive answer to that, but it seems it should also go
> at the end.  We're really micro-optimizing here, though.

That's a good point, I put it first because checking value is much
faster than calling a function, but NUL is super rare which I didn't
consider at the time.

-- 
Mikael Magnusson