Hi Mingye, sorry it took so long but I changed the internal handling of those strings and it should work better now. Could you give me your updated translation file so I could try it? Or you can try yourself. However, the change is still in minicom's hg repository. Get it with hg clone https://alioth.debian.org/anonscm/hg/minicom/
Thanks, Adam On Tue Apr 26, 2016 at 20:45:09 -0400, Mingye Wang (Arthur2e5) wrote: > On 4/26/2016 18:23, Adam Lackorzynski wrote: > > Hi, > > > > thanks for letting me know of those issues! > Thanks for responding to my report :) > > It seems that you have CC'ed your message to Debian BTS submission > instead of Debbugs#822490. Assuming that's done by mistake, I am quoting > all your message and CC'ing it back to the bug so your reply will be > visible on the bug info page for others. > > > > > On Wed Apr 20, 2016 at 12:04:37 -0400, Mingye Wang (Arthur2e5) wrote: > >> Package: minicom > >> Version: 2.7-1 > >> > >> // omitted > >> > >> 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. > > > > Probably a wrapper for wcswidth() will do here that counts unprintable > > characters as 1 char/column (and just ignoring the speciality of TAB). > wcswidth(wchar_t*, size_t) is essentially finding the sum of the return > values of wcwidth(wchar_t) for all the wchars in the range (, and > returning -1 when wcwidth gives -1). Hence you will actually end up > doing a wcwidth(wchar_t) wrapper. > > > > >> // omitted > >> > >> 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. > > > > Yes, needs to be fixed. > > > >> 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). > > > > Ok, good to know, thanks. > > > > Adam > > > > -- > Regards, > > Arthur2e5
