Add solution for East Asian Width Problem

[hamano]

Is your feature request related to a problem? Please describe.

We would like to express our gratitude from the Far East for implementing the treat_east_asian_ambiguous_width_as_wide option in wezterm. However, this option is a adhoc workaround and is inadequate.

• fullwidth for box drawing breaks the TUI screen.
• fullwidth for block elements breaks the progress bar.
• Inconsistent circled numbers width ⓪①..⑳㉑.
• Traditional Japanese charactor width does not match the Unicode recommended width.

Describe the solution you'd like

Regarding the EAW issue, better solutions:

1. Using wcswidth()
2. Set cellwidth for code points.

Since wezterm is a cross-platform application, using wcswidth() might not be appropriate. I propose adding a cellwidth configuration option to wezterm. This is a feature provided by mlterm, Emacs, and Vim, and it offers a practical solution to the ambiguous Unicode standard. With this option, it is possible to unify character widths across terminal, shell, and text editors.

Based on vim's setcellwidths(), I propose the following syntax for the settings

config.cellwidths = {
  {0x2460, 0x2473, 2}, -- ①..⑳
  {0x24EA, 0x24EA, 2}, -- ⓪
  {0x2668, 0x2668, 2}, -- ♨
  {0xF113, 0xF113, 2}, -- 
}

However, it seems that keyword omission is not preferred in wezterm

config.cellwidths = {
  {first = 0x2460, last = 0x2473, width = 2}, -- ①..⑳
  {first = 0x24EA, last = 0x24EA, width = 2}, -- ⓪
  {first = 0x2668, last = 0x2668, width = 2}, -- ♨
  {first = 0xF113, last = 0xF113, width = 2}, -- 
}

I will handle the actual work and submit a pull request. Additionally, I understand that there is a difference in perspective regarding the EAW issue between Latin users and CJK users. If additional explanations are needed regarding the difficulties faced by the CJK users, I am more than willing to provide them.

[hamano]

ref: https://github.com/wez/wezterm/issues/1888

[NathanCummings]

Is the issue I am having in #6228 related to this do you think? Particularly look at my most recent comment where running wezterm ls-fonts --list-system shows many asian characters not being displayed properly.

[hamano]

@NathanCummings #6228 is not EAW issue. https://github.com/wez/wezterm/issues/6228#issuecomment-2423829010

[wez]

This should be resolved now in main.

It typically takes about an hour before commits are available as nightly builds for all platforms. Linux builds are the fastest to build and are often available within about 20 minutes. Windows and macOS builds take a bit longer.

Please take a few moments to try out the fix and let me know how that works out. You can find the nightly downloads for your system in the wezterm installation docs.

If you prefer to use packages provided by your distribution or package manager of choice and don't want to replace that with a nightly download, keep in mind that you can download portable packages (eg: a .dmg file on macOS, a .zip file on Windows and an .AppImage file on Linux) that can be run without permanently installing or replacing an existing package, and can then simply be deleted once you no longer need them.

If you are eager and can build from source then you may be able to try this out more quickly.

[github-actions[bot]]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.