> From: Bruno Haible <[email protected]> > Cc: [email protected], [email protected] > Date: Mon, 09 Oct 2023 19:18:25 +0200 > > Eli Zaretskii wrote: > > > I just tried it now: On Linux (Ubuntu 22.04), in a de_DE.UTF-8 locale, > > Oops, typo: What I tested was the de_DE.ISO-8859-1 locale: > $ export LC_ALL=de_DE.ISO-8859-1
So wcwidth in ISO-8895-1 locale returns 1 for U+0237? Even though U+0237 cannot be encoded in ISO-8895-1? And iswprint returns non-zero for it in that locale? Or does the Texinfo test suite forces the locale to something UTF-8? > > Since U+0237 is not printable in my locale (it isn't supported by the > > system codepage), the value -1 is correct. Am I missing something? > > True. But why don't we see the same test failure on glibc and on FreeBSD > systems, then, in a locale with ISO-8859-1 encoding? Good question. Maybe they interpret the Posix standards differently (if the locale is not forced by the test suite). > > > This "simpler approximation" would not return a good result when wc > > > is a control character (such as CR, LF, TAB, or such). It is important > > > that the caller of wcwidth() or wcswidth() is able to recognize that > > > the string as a whole does not have a definite width. > > > > It is still better than returning -1, don't you agree? > > No, I don't agree. Returning -1 tells the caller "watch out, you cannot > assume anything about printed outline of this string". I meant "better for Texinfo when it generates Info manuals", not in general. > > But for some reason you completely ignored my more general comment > > about what Texinfo needs from wcwidth. > > That's because I am not familiar with the Texinfo code. I don't know > whether and where Texinfo calls wcwidth(), and I don't know with which > expectations it does so. It calls wcwidth to know how many columns a character will take, in order to fill lines, when it generates manuals in the Info format.
