Inconsistent border on a CJK Windows 10

[skywind3000]

My code page is 936，here is the screenshot, note the drop down window border:

Have you tested it on a CJK Windows ?

[diaowinner]

fyi I've searched a lot about how this bug happens. first, the default font in your screenshot's software - conhost, is SimSun (aka Zhongyi Song, actually it's NSimSun). Zhongyi Song has a set of full-width box drawing symbols, unlike general fonts such as Consolas, it's half-width:

notice that the usage of conhost is common, considering to support full-width box drawings should be a good question.

---

(Chinese translation) 我考究了这玩意是咋发生的，你用的终端是 conhost 程序，调用的应该是系统默认的“宋体”（实际上是“新宋体”）。这款字体把制表符设成全宽（全角）的，而别的终端字体，例如说 Consolas，把制表符设成半宽（半角）了。

所以这个问题可以归结于，是否让这个项目支持全宽的制表符。顺便一提用全宽的人还挺多的。

[lhecker]

This editor is mostly written with Windows Terminal in mind, less so with conhost, particularly on Windows 10. This is not because I dislike conhost, but rather for a technical problem:

Conhost traditionally measures the actual glyph (character) width when drawing ambiguous width characters to decide how many columns it should occupy. Modern terminals on the other hand assign them a width of 1 column. The ellipsis glyph "…" used there is ambiguous width (see "East Asian Width (ea)"): https://codepoints.net/U+2026

That said, I actually tried avoiding ambiguous width glyphs when I wrote this editor. I honestly didn't anticipate that "…" would also be ambiguous width... Maybe I'll swap it out with "..."? That would be quite annoying though, because "…" just looks so much better. 😢

[skywind3000]

No idea about the character width, but vim works fine in conhost:

yedit can handle this correctly as well:

Windows 10 still has the largest user base and this situation will continue for years in some regions while windows-terminal is not installed by default. In some restricted environment, like network is not accessible, conhost is the only available option in many ways.

As the text editor officially provided by Microsoft, I believe conhost is worth to support.

[lhecker]

You don't have to convince me. It's tagged as a bug, and I even said:

Maybe I'll swap it out with "..."? That would be quite annoying though, because "…" just looks so much better. 😢

The reason I tagged it as "low" is because the alignment of menus objectively isn't that urgent to be fixed. It's still a bug, just not an urgent one.

That said, if you have the option to use Windows Terminal, please use it.

[driver1998]

That said, if edit is going to be included in WinPE and ServerCore and the like, conhost issues will need to be resolved anyway.

Interestingly to see the line-drawing characters are not affected, are there non-ambiguous-width variants of those?

[roytam1]

yedit can handle this correctly as well:

it is hard to say "it handles fine", as it draws "full-width" characters in both borders and scroll bar.
BTW there is yedit -a to tell yedit using ASCII characters to avoid this. (but it can't handle drawing dual-width characters(and counting them as "single-width") in text boxes)

[lhecker]

Interestingly to see the line-drawing characters are not affected, are there non-ambiguous-width variants of those?

That's correct. Box drawing characters are expected to be narrow. For instance: https://codepoints.net/U+2502 or https://codepoints.net/U+2584

[roytam1]

Box drawing characters are expected to be narrow.

but legacy codepages disagree.

[driver1998]

but legacy codepages disagree.

Edit forces codepage to be 65001 anyway.

[roytam1]

but legacy codepages disagree.

Edit forces codepage to be 65001 anyway.

but fonts with legacy codepage compatibility will just following legacy codepage specifications to make them double space wide.
(for example, CP932 has cyrillic alphabet in full-width form)

[lhecker]

I apologize but I believe the current discussion is unrelated to this particular bug.
If codepages become an issue in the future, that'd be a separate bug we could file here.