diff options
| author | woot <worrawutp@gmail.com> | 2026-09-10 10:30:07 +0700 |
|---|---|---|
| committer | bfredl <bjorn.linse@gmail.com> | 2026-09-15 11:59:01 +0200 |
| commit | 4397aad1d3055928a4ac51a55464b82edba629d8 (patch) | |
| tree | ded0861a3d363dcd96c7ae2bccdbd48244ff7eab /runtime/lua/vim/provider/python.lua | |
| parent | 13f1f31ec29c3be1227544988a0f193480f5e9a7 (diff) | |
| download | rneovim-4397aad1d3055928a4ac51a55464b82edba629d8.tar.gz rneovim-4397aad1d3055928a4ac51a55464b82edba629d8.tar.bz2 rneovim-4397aad1d3055928a4ac51a55464b82edba629d8.zip | |
fix(mbyte): spacing marks need their own display cell
Problem:
strdisplaywidth('ทำ') is 1, but that cluster needs two cells. A SpacingMark has
positive advance width (Unicode core spec D55), so it cannot share its base's
cell: no Thai font fits a consonant plus SARA AM (U+0E33) in one cell, the
narrowest needing 119% of one and most 180-210%, measured against a 0.600 em
cell. UAX#29 GB9a keeps the mark in its base's cluster, which is correct for
segmentation and says nothing about width.
setcellwidths() cannot work around it, because the collapse is per cluster, not
per codepoint.
Vim reports 2 here. Devanagari and Bengali matras and Khmer and Tamil vowel
signs are the same case.
Solution:
Add a cell for each remaining codepoint in the cluster whose boundclass is
UTF8PROC_BOUNDCLASS_SPACINGMARK, clamped to the maximum cells per cluster.
Segmentation is untouched, so the cursor and selection still treat the cluster
as one unit.
U+FF9E and U+FF9F, the halfwidth katakana sound marks, are Grapheme_Extend
rather than SpacingMark, so they are matched separately. This is not a general
solution for grapheme extenders that carry width -- that needs a queryable
table -- but it does fix the reported regressions for Thai and Japanese
(refs #34733).
AI-assisted
fixes #34733
Diffstat (limited to 'runtime/lua/vim/provider/python.lua')
0 files changed, 0 insertions, 0 deletions