You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
Using wcswidth()
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
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.
The text was updated successfully, but these errors were encountered:
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.
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.
Describe the solution you'd like
Regarding the EAW issue, better solutions:
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 settingsHowever, it seems that keyword omission is not preferred in wezterm
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.
The text was updated successfully, but these errors were encountered: