Default value for the `ambiguousIsNarrow` option

[ehmicky]

The default value for the ambiguousIsNarrow option introduced in 5.1.0 might surprise some users. It might also be a breaking change for a few of them. For example, some characters used fairly commonly in terminal outputs like ± now have a width of 2 instead of 1 by default (since ambiguousIsNarrow defaults to false). In my case, this broke the line wrapping logic of my CLI application.

The best value for this option seems to depend on whether the user is using an East Asian legacy character encoding. Are those legacy character encodings more common among East Asian languages users than non-legacy ones? If not, should the default value be switched to true?

Another solution would be to make the default value depend on the machine's locale? os-locale could be used for that purpose, providing it is memoized (since it spawns processes, which can be slow).

If the default value does remain false, since this might be unexpected for developers of other languages, it might make sense to document that users of this library should tweak this option based on whether they expect to use an East Asian legacy character encoding.

[sindresorhus]

You are right. I missed this during the review.

Ambiguous characters behave like wide or narrow characters depending on the context (language tag, script identification, associated font, source of data, or explicit markup; all can provide the context). If the context cannot be established reliably, they should be treated as narrow characters by default.

• http://www.unicode.org/reports/tr11/tr11-38.html

[ehmicky]

I missed this sentence from the Unicode recommendations, nice catch!
Thanks for fixing this @sindresorhus!