feat(console): add unicodeWidth for TTY text layout

[lionel-rowe]

Closes #3296.

A TypeScript port of the unicode-width Rust crate, which looks up the nominal width of Unicode characters. This allows calculating the expected physical column width of a string in TTY-like environments when combined with stripColor from fmt/colors.ts.

[iuioiua]

I'm -1 on this PR as I don't believe it's worth the added complexity of a Rust implementation. We recently deprecated the Rust implementation of encoding/varint for this same reason.

I'm also unsure whether this functionality is sought after enough to be in the Standard Library. I don't feel strongly about this, though.

That's not to say such functionality would be valuable in a 3rd party module! 🙂

[lionel-rowe]

I don't believe it's worth the added complexity of a Rust implementation

To clarify, this is a TypeScript port of a Rust crate, not a WASM implementation. The Rust code is just a thin wrapper around the crate, used for checking equivalency of results during testing, and isn't imported by the module code itself.

[kt3k]

std/string_width top level module sounds too specific to me. How about std/console (or something similar)?

[kt3k]

string_width/_scripts/generateData.ts

We prefer _tools over _scripts. Also we usually use snake case for file names (generateData.ts -> generate_data.ts

[kt3k]

The implementation looks good to me.

[kt3k]

It's bikeshedding topic, but I'm wondering between 2 api name candidates: stringWidth and unicodeWidth. Does anyone have preference between these? cc @iuioiua @lino-levan @timreichen @jsejcksn

[lionel-rowe]

It's bikeshedding topic, but I'm wondering between 2 api name candidates: stringWidth and unicodeWidth

FWIW, while I don't think the name unicodeWidth is ideal as it could perpetuate the myth that Unicode strings are some special type of strings distinct from "ASCII strings", it at least gives a hint at the type of functionality it provides (grabbing width data for the constituent characters as specified by Unicode), while not implying it does something it doesn't (e.g. stripping ANSI codes to give a more accurate physical width in TTYs). The first version of this PR used the name stringWidth as it combined both functions, until you pointed out that the ANSI-stripping functionality is already provided in fmt/colors.js.

[lino-levan]

It's bikeshedding topic, but I'm wondering between 2 api name candidates: stringWidth and unicodeWidth

I've done a bit of pondering (my original response before I cut it down to this was ~half a page long), but I think that stringWidth makes the most sense to me. At the end of the day, this method needs to be discoverable and I think that even if stringWidth isn't the best description of what it doesn't do, it is a very clear description of what it does. unicodeWidth is harder to search for and the functionality (imo) isn't immediately obvious. That being said, I don't feel super strongly either way. Just my 2 cents.

[jsejcksn]

It's bikeshedding topic, but I'm wondering between 2 api name candidates: stringWidth and unicodeWidth. Does anyone have preference between these?

I'm in favor of keeping unicodeWidth.

• Socratic: What's the difference between string width and string length?

  The term width is ambiguous/overloaded. The usage here is very technical, and, for that reason alone, I think it makes sense to use unicode because it helps disambiguate.

• This is a port and I think porting the name is sensible as well — there's nothing special about the context of Deno which invalidates it (compared to other ports where idioms don't translate), and keeping the name will give confidence to Deno users who are already familiar with the upstream library.

[timreichen]

stringWidth seems more familiar to me, but I don't have a strong opinion.

[kt3k]

LGTM. Thanks for your contribution @lionel-rowe

Also thanks all for discussions and reviews