}
/* We assume that we don't screw up and retrieve something out of range. */
+ if (line == NULL) {
+ fatalbox("line==NULL in terminal.c\n"
+ "lineno=%d y=%d w=%d h=%d\n"
+ "count(scrollback=%p)=%d\n"
+ "count(screen=%p)=%d\n"
+ "count(alt=%p)=%d alt_sblines=%d\n"
+ "whichtree=%p treeindex=%d\n\n"
+ "Please contact <putty@projects.tartarus.org> "
+ "and pass on the above information.",
+ lineno, y, term->cols, term->rows,
+ term->scrollback, count234(term->scrollback),
+ term->screen, count234(term->screen),
+ term->alt_screen, count234(term->alt_screen), term->alt_sblines,
+ whichtree, treeindex);
+ }
assert(line != NULL);
resizeline(term, line, term->cols);
if (DIRECT_CHAR(c))
width = 1;
if (!width)
- width = wcwidth((wchar_t) c);
+ width = (term->cfg.cjk_ambig_wide ?
+ mk_wcwidth_cjk((wchar_t) c) :
+ mk_wcwidth((wchar_t) c));
if (term->wrapnext && term->wrap && width > 0) {
cline->lattr |= LATTR_WRAPPED;
* 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.
*