Fwd: [i18n] minicom does not live[work] well with multicol characters

[Mingye Wang (Arthur2e5)]

各位，

此處轉發的信件是對 minicom 字寬處理錯誤的 Debian 錯誤回報（#821936）。轉
過來是因為 zh_TW 也用中文（廢話），並且 minicom zh_TW 在 TP 上面有翻譯，
如果有人注意到這個問題的話也可以去看看。

Hello all,

This forwarded message is a Debian bug report for problems found in
column width handing in minicom. Since minicom is translated in Japanese
on TP, I guess someone else here has noticed this bug and will be
interested in tracking this bug report.


http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=821936

-------- Forwarded Message --------
Subject: [i18n] minicom does not live well with multicol characters
Date: Wed, 20 Apr 2016 12:04:37 -0400
From: Mingye Wang (Arthur2e5) <>
To: submit [at] bugs.debian.org
CC: Jeff Bai <>, Ji ZhengYu <>

Package: minicom
Version: 2.7-1

A few months ago I was doing some minicom zh_CN l10n on
TranslationProject.org. Since the work is has been assigned to someone
else, I was not able to submit the done files. Interestingly, the
coordinator of the zh_CN language actually presented me with an extra
reason why they are not accepting strings (even if someone else has done
that years ago) -- translating minicom makes the UI a mess [1].
[1]: https://groups.google.com/d/topic/i18n-zh/X-FCRHzWuYc/discussion

multi-column scripts like CJK and emoji takes up multiple terminal
columns for each character. (For the two specifically, well, two cols.)
However, these segments in minicom appears to be ignoring all such
characters:

config.c:
> static void dologopt(void)
> {
> /* ... */
> while(1) {
> mc_wlocate(w, mbslen(question) + 5, 5);

This mc_wlocate call assumes that mbslen(str) is the colomn width of
str. However, due to the reasons mentions above, CJK strings like "è¦ ä¿®
改哪个选项？" will end up giving a cursor stuck in the middle.

wcswidth(wchar_t *) may be a better solution, but you may want to add
some comments to ask translations not to use tabs (which screws up
things in the current implementation too.) Unprintable chars (including
ctrl chars like tab and newline) in wcswidth will cause it to return -1.

window.c:
> void mc_wputc(WIN *win, wchar_t c)
> {
> /* ... */
> if (win->cury == win->sy2 - win->y1 + 1)

The windows x/y knowledge is also crippled here. For single-char width
info, use wcwidth(wchar_t). Like wcswidth, it returns -1 for unprintable
chars.

Note that emoji suport in glibc wcwidth() comes with Unicode 7.0 support
in glibc, which is in glibc 2.22. Some extra even newer emojis require
Unicode 8.0 (glibc 2.23).

--
Regards,

Arthur2e5