Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add solution for East Asian Width Problem #6289

Open
hamano opened this issue Oct 17, 2024 · 3 comments
Open

Add solution for East Asian Width Problem #6289

hamano opened this issue Oct 17, 2024 · 3 comments
Labels
enhancement New feature or request

Comments

@hamano
Copy link

hamano commented Oct 17, 2024

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 hamano added the enhancement New feature or request label Oct 17, 2024
hamano added a commit to hamano/wezterm that referenced this issue Oct 17, 2024
@hamano
Copy link
Author

hamano commented Oct 17, 2024

ref: #1888

hamano added a commit to hamano/wezterm that referenced this issue Oct 18, 2024
@NathanCummings
Copy link

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
Copy link
Author

hamano commented Oct 19, 2024

@NathanCummings #6228 is not EAW issue.
#6228 (comment)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants