Hi I can tell you for certain that I would use mbwidth() and mbvis() in tmux. Functions to answer things like "is this string valid UTF-8?" and "how many codepoints is this string?" would also be good.
If the consensus is to use the locale.h goo I will do that but I would prefer something simpler and UTF-8 only in libutil. I think Damien would like a vis() equivalent in ssh. file will use vis() and maybe a isvalid() function. Pledge is a good example. Why not do the same as Theo did with pledge? Get something into libutil first, and keep all the userland diffs in a directory on cvs until libutil is ready in tree and a good set of userland is settled and ready for commit. That way we don't need to bump libutil or risk breaking half of /bin in every snapshot. I can come up with a diff for libutil if I'm not going to be wasting my time... On Tue, Oct 27, 2015 at 03:54:30AM -0400, Ted Unangst wrote: > Anthony J. Bentley wrote: > > Stefan Sperling writes: > > > On Mon, Oct 26, 2015 at 03:58:58PM -0600, Anthony J. Bentley wrote: > > > > "Ted Unangst" writes: > > > > > it only gets deeper and thicker... > > > > > > > > Indeed. > > > > > > > > Here's a shorter implementation. Like colorls(1), it uses wide > > > > characters (only within the putname() function) but is slightly cleaned > > > > up and simplified. > > > > > > Is it really shorter if you follow the libc code paths this is calling? > > > > No, it's not. But that's not inherent to wchar_t, only to the Citrus > > stuff that infests our libc. As Citrus gets cleaned up, this works > > better instantly. And if we instead come up with better functions for > > doing this kind of thing: > > Fixing citrus is a pretty massive effort in itself. I'd prefer to see the > replacement code prove itself as a separate API first, then we can remove > citrus and change the wchar functions to use the new code. I'm less confident > in a "meet in the middle" effort where we convert to wchar while > simultanesouly > hoping the wchar code gets better. > > In the mean time, maybe we should also look at a few more utilities. We seem > to have some intuition that mbwidth() etc. will be useful, and maybe mbvis(), > but we don't really know. So far I've poked at ul, rs, and ls. Then we've gone > around in circles polishing those particular turds, but not much effort was > spent looking at other utilities. > > What about wc? file? du? top? cut? vis??? > > Will adding utf-8/unicode support to each of those look the same? Or will > every utility be different? > > Theo probably converted 100 utilities to use pledge before anything was > committed to the tree. At the current rate, utf-8 will take another 10 years > before anything happens. > > Additionally, I think all diffs to fix ls should be accompanied by before > and after ktrace output. :) >
