Add an option to use wcwidth_cjk() instead of wcwidth(), as several people
[u/mdw/putty] / terminal.c
index 0ab1414..904f1b8 100644 (file)
@@ -1017,7 +1017,7 @@ static termline *lineptr(Terminal *term, int y, int lineno, int screen)
     }
 
     /* We assume that we don't screw up and retrieve something out of range. */
-    if (line != NULL) {
+    if (line == NULL) {
        fatalbox("line==NULL in terminal.c\n"
                 "lineno=%d y=%d w=%d h=%d\n"
                 "count(scrollback=%p)=%d\n"
@@ -2845,7 +2845,9 @@ static void term_out(Terminal *term)
                    if (DIRECT_CHAR(c))
                        width = 1;
                    if (!width)
-                       width = wcwidth((wchar_t) c);
+                       width = (term->cfg.cjk_ambig_wide ?
+                                wcwidth_cjk((wchar_t) c) :
+                                wcwidth((wchar_t) c));
 
                    if (term->wrapnext && term->wrap && width > 0) {
                        cline->lattr |= LATTR_WRAPPED;
@@ -6231,13 +6233,13 @@ int term_data(Terminal *term, int is_stderr, const char *data, int len)
      * the remote side needing to wait until term_out() has cleared
      * a backlog.
      *
-     * This is a slightly suboptimal way to deal with SSH2 - in
+     * This is a slightly suboptimal way to deal with SSH-2 - in
      * principle, the window mechanism would allow us to continue
      * to accept data on forwarded ports and X connections even
      * while the terminal processing was going slowly - but we
      * can't do the 100% right thing without moving the terminal
      * processing into a separate thread, and that might hurt
-     * portability. So we manage stdout buffering the old SSH1 way:
+     * portability. So we manage stdout buffering the old SSH-1 way:
      * if the terminal processing goes slowly, the whole SSH
      * connection stops accepting data until it's ready.
      *