Re: Cannot paste unicode <0221>, <0234> - <024f>

[Sebastian Gniazdowski <psprint@zdharma.org>]

On 28 kwietnia 2017 at 16:42:17, Peter Stephenson (p.stephenson@samsung.com) wrote:
> It might be possible to rely *only* on wcwidth() in cases where we're
> using a replacement? Does anyone from the Apple world have any
> opinions?
>  
> pws
>  
> diff --git a/Src/Zle/zle_refresh.c b/Src/Zle/zle_refresh.c

I've checked the patch, no luck, but I knew what to track, so I've added:

    fprintf( stderr, "Path 1, char/string: %S\n", t );
and
    fprintf( stderr, "Path 3, char/string: %S, iswprint:%d, wcwidth: %d\n", t, iswprint(*t), WCWIDTH(*t));

for printable / unprintable if-paths, and the result is:

Path 1, char/string: ȯȰȱȲȳȴȵȶȷȸȹ
Path 1, char/string: ȰȱȲȳȴȵȶȷȸȹ
Path 1, char/string: ȱȲȳȴȵȶȷȸȹ
Path 1, char/string: Ȳȳȴȵȶȷȸȹ
Path 1, char/string: ȳȴȵȶȷȸȹ
Path 3, char/string: ȴȵȶȷȸȹ, iswprint:0, wcwidth: -1
Path 3, char/string: ȵȶȷȸȹ, iswprint:0, wcwidth: -1
Path 3, char/string: ȶȷȸȹ, iswprint:0, wcwidth: -1
Path 3, char/string: ȷȸȹ, iswprint:0, wcwidth: -1
Path 3, char/string: ȸȹ, iswprint:0, wcwidth: -1
Path 3, char/string: ȹ, iswprint:0, wcwidth: -1

What's interesting, once or twice the print looked like following (recompile fixed this):

Path 1, char/string: ȯȰȱȲȳȴȵȶȷȸȹiⱁ
                                  ÍA䰂Ӄ࢑࠱䙁怲དྷĝ²ũǝ
Path 1, char/string: ȰȱȲȳȴȵȶȷȸȹiⱁ
                                 ÍA䰂Ӄ࢑࠱䙁怲དྷĝ²ũǝ
Path 1, char/string: ȱȲȳȴȵȶȷȸȹiⱁ
                                ÍA䰂Ӄ࢑࠱䙁怲དྷĝ²ũǝ
...

like if printf() wasn't sure itself should %S print those characters correctly or not. That said, vim or mentioned bash somehow manage this, just as a reference point if stdlib is broken or not(-really).

-- 
Sebastian Gniazdowski