I'll report back my findings in a paper. It may not be solvable perfectly
but I think we can come up with a good practical approximation that
addresses the main use case and I'm fine with not addressing esoteric ones.
People somehow manage to write CLIs that do this and work with fancy emojis
and Asian scripts even in C =).

- Victor

On Fri, Sep 13, 2019 at 6:57 AM Niall Douglas <s_sourceforge_at_[hidden]>
wrote:

> On 13/09/2019 14:36, Victor Zverovich wrote:
> >> Instead of inventing something in the abstract, a good next step would
> >> be to figure out how (in UTF-8 mode) Apple Terminal, Gnome Terminal,
> >> Konsole, and the new Windows Terminal determine how many terminal
> >> display column a string takes. (I'm not volunteering.)
> >
> > I'm volunteering to do this since improving handling of width is already
> > on my TODO list for the fmt library.
>
> I'll be interested in what you come up with on this, as I don't think
> this solvable.
>
> For example, imagine formatting into a file, and then that file is
> rendered onto a console.
>
> Another example: imagine formatting into a clipboard, which on Windows
> and POSIX might involve three or four renditions into differing formats
> and encodings. Then the consumer of the clipboard chooses an unknown one
> of those renditions, and reinterprets it in some unknown way into a
> paste into some document.
>
> Personally speaking, I think the best course is to declare codepoint or
> byte based formatting widths, and draw a line under it.
>
> Niall
> _______________________________________________
> SG16 Unicode mailing list
> Unicode_at_[hidden]
> http://www.open-std.org/mailman/listinfo/unicode
>