On Thu, Jan 22, 2026 at 04:20:11PM +0000, Gavin Smith wrote: > On Thu, Jan 22, 2026 at 01:16:36PM +0100, Patrice Dumas wrote: > > Yes as I said, I don't think it is worth it:
Ok, no problem with that. I think that it would be important to have a comment in printed_representation raw_utf8_output_p explaining the choice with the kind of idea you say below, such that it is clear that the limitation is on purpose, and is not something that could be improved. If somebody sees the code later on it could help. > > > > Reading the UTF-8 sequence, obtaining the codepoint and calling wcwidth > > > seems to me to be a unnecessary complication for a marginal use case. > > I don't see why we should add a libunistring dependency and more code to deal > with this case. > > It is only a problem on particular terminals on MS-Windows (which is an OS > family of secondary importance for the GNU Project). > > Short of rewriting the whole program to use libunistring instead of locale- > dependent functions, there will likely be broken behaviour in one place or > another, anyway. > > The fix I posted seems to work well enough and allows users to read UTF-8 > manuals under such condiitions. > > > >
