Re: [bug #42233] [PATCH] wcwidth(3) used on UCS4/UTF-32 codepoints

[Steffen Nurpmeso]

 |Steffen has withdrawn most/all of his other patches and even after reading

I do not know what this has to do with this bug.

 |this report a few times I'm not clear on what exactly the problem is supposed
 |to be.
 |
 |The "solution", "drop gnulib", is not likely, especially not during an RC
 |cycle.

Sorry, what??

 |This could be reopened if we had a simple, reproducible case of groff actually
 |misbehaving.
 |
 |> I think currently groff makes false use of wcwidth(3): if it finds the
 |`unicode' property in a `DESC' file it uses wcwidth(3) to determine the visual
 |width, not taking into account the current locale, but which wcwidth(3)
 |depends upon.
 |
 |I don't understand[.]

I am too old for this shit, really.  I therefore agree.

 |[.] why the width of a Unicode character would be
 |locale-dependent.  As I understand it, the width property (half-width,
 |full-width, undefined) is determined on a per-codepoint basis and while it
 |might vary, there's no reason to expect it to vary based on the _locale_.
 |More likely, I think, it would vary due to choices taken by a font vendor, and
 |people using the font would be forced to adapt.
 |
 |Closing.

I think there was a ML thread by the time i opened the bug report,
where the according GNUlib function that could simply be used to
correctly implement the given was named.
Then that piece of cake would be correct, despite possibly
non-capable surroundings.
Just my one cent.

Out for cycling, ciao!

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)