| Konsole |
Libc's wcwidth(), while not perfect, is used by most programs.
Implementation compatibility is necessary to avoid problems with string
width calculation and proper cursor movement.
The original wcwidth implementation files:
are not removed yet.
BUG: 378124
BUG: 392171
BUG: 339439
Depends on D12236
Vertical lines below should align
Code Ch Source bug U+26A1 |β‘| 378124 U+2615 |β| 392171 U+26EA |βͺ| 392171 U+1D11E |π | 339439
| No Linters Available |
| No Unit Test Coverage |
sorry can you rebase this? it doesn't apply cleanly anylonger - also, can you not delete konsole_wcwidth.* for now
Thanks, I wish there was a better way of rebasing other than asking owner to do it.
On the last line, the right | doesn't line up w/ the other rows
In vim, they line up - not git and not when I cat a file containing them.
Sounds like glibc <2.26 (Unicode <9), where first three were not "wide".
Vim uses its own wcwidth.
QTest::addRow is only in Qt5.9 - you'll need to add a check - it fails on freebsd
Also, I'm a little concerned that we're going to start having to request what version of libc users's have in bug reports. And then have to research how that version uses wcwidth. Where as now, we know everyone uses konsole_wcwidth.
You are right here. I have wcwidth maps from several glibcs, so I am able to just grep a code point and verify if it has different width in some version. Sadly, this is not easily downloadable from some reliable source, so it is not an option to recommend.
On the other hand, were there other bugs than "character width is wrong" or "cursor disappears on character/backspaces too much" (where it is obvious the width is wrong for the user), related to character width?
BTW. Why there is no "Please attach konsole --show-info-for-a-bug-report output to the bug" and respective switch in Konsole, and custom additional info defined by a program in "report bug" feature? Could help in some cases, not only with this.
Where as now, we know everyone uses konsole_wcwidth.
Sure, but we'll get less bugs than with konsole_wcwidth - people with newer libc won't have them, people with older version will get about as much as with konsole_wcwidth. Also, using system's wcwidth fixes bugs like "cursor in bash moves wrong" (392171) and similar problems with programs using system's wcwidth, for everyone.
The ultimate (and complex) solution I was thinking about would be something like:
This would solve problems with custom implementations, different libc, user preferences (including "Unicode is wrong, I want it this way" or improved powerline-like features). But due to complexity it probably won't appear soon.
OK, I agree that a debug/info command line would be a good idea. I wonder if that can be done in the crash system/dialog. We'd need it outside crashes as well.
On my FreeBSD, the width tests fail 20000-10 actual 1, expected 2
Thanks for the info. I did a quick research and looks like width data is not provided for code points above 0xffff since FreeBSD 11 (it defaults to 1, or -1 when code point is not assigned). This is obviously not acceptable.
I am abandoning this revision. I'll generate width data from Unicode 10 and UTS#51 v5, and create a new review request.