Hong Minhee (洪 民憙)

@item4 Other than string literals are not covered by this patch. I would appreciate if someone works on it further.

Here's also few more points we need to address in the future: - There are zero-width characters like U+200B ZERO WIDTH SPACE. They are designated `N` (narrow) according to `East_Asian_Width`,...

I added a fast path for ASCII-only strings as well!

> Consider using [wcwidth](https://github.com/jquast/wcwidth)? In my experience in other projects this is more accurate for control characters, non-asian characters, etc. (see [this](https://github.com/masaccio/compact-json/issues/4#issuecomment-1357049123)) Also wcwidth uses `lru_cache` which should be helpful...

If we decide to generate Black's own table to avoid a runtime dependency on wcwidth, should the generated table be version-controlled, or should it be generated at build time (through...

Now `char_width()` depends on the generated `wcwidth()` table instead of `unicodedata.east_asian_width()`, and it's LRU-cached. I also changed the fast path condition of `str_width()` to address [what @ZeroRin pointed out](https://github.com/psf/black/pull/3445#discussion_r1062985596). The...

@JelleZijlstra I addressed things you pointed out. Could you take a look again?

I rebased commits on the latest main and resolved conflicts (mostly from #1879). Please take a look again!

The test suite apparently failed on the CI job. Should I try to fix it?

I tried to address this (partly): . However, I am not sure if my approach is appropriate and I implemented things properly. I would appreciate if someone take a look...