Re: PATCH: Unicode additions, next phase.

[Clint Adams <clint@xxxxxxx>]

> Plus we'll probably need to have wcwidth on the menu at some

Oh dear.. also any memory allocations based on winw have to be modified.

> point... not sure if that helps with wide characters that are control
> characters (do these exist?), probably not.  I'd be tempted to see if
> control characters were converted to a single byte string, if they do
> print them as at present, and if they don't just skip them; same for
> conversion failures, although that shouldn't happen for characters that
> convert to 7-bit ASCII anyway.

This uses '?' for both eventualities.  That might obscure character
conversion errors.

Index: Src/Zle/zle_refresh.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/Zle/zle_refresh.c,v
retrieving revision 1.15
diff -u -r1.15 zle_refresh.c
--- Src/Zle/zle_refresh.c	26 Jan 2005 13:39:52 -0000	1.15
+++ Src/Zle/zle_refresh.c	26 Jan 2005 14:24:23 -0000
@@ -478,7 +478,7 @@
 		nextline
 	    }
 #ifdef ZLE_UNICODE_SUPPORT
-# error What to do here
+	    *s++ = ((*t == 127) || (*t > 255)) ? '?' : (*t | '@');
 #else
 	    *s++ = (*t == 127) ? '?' : (*t | '@');
 #endif
@@ -488,7 +488,7 @@
 
 	    i = wcrtomb(s, *t, &shiftstate);
 	    if (i == -1) {
-		/* error; what to do? */
+		*s++ = '?';
 	    } else {
 		s += i;
 	    }