https://bugs.kde.org/show_bug.cgi?id=378124
Bug ID: 378124
Summary: Character width for HIGH VOLTAGE SIGN possibly wrong
Product: konsole
Version: 16.12.0
Platform: Debian unstable
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: NOR
Component: font
Assignee: konsole-de...@kde.org
Reporter: thomas+kdeb...@luzat.com
Target Milestone: ---
Created attachment 104749
--> https://bugs.kde.org/attachment.cgi?id=104749&action=edit
Third-party terminal screenshot to show the symbol/prompt
I am using konsole with Source Code Pro font, (oh-my-)zsh and agnoster theme.
This looks similar to attached screenshot, taken from
https://gist.github.com/agnoster/3712874 When becoming root the command prompt
contains Unicode character \u26a1 (HIGH VOLTAGE SIGN). The character is
rendered with a 1 character width. Problems with that character are
reproducible with other shells by just copy & pasting the Unicode character
into some konsole. Two symptoms of the problem are:
1. In the configuration above: When using tab completion (e.g.: enter ab, press
TAB), the prompt doesn't show "ab" but becomes "aab". That is, the completion
is inserted with an offset of one character. Trying to backspace 3 times or
delete the line with C-u only the "ab" gets deleted.
2. Easier to reproduce: Copy & paste the character \u26a1 into some shell
running in konsole. Backspace or C-u make konsole move 2 characters backwards
instead of one, deleting parts of the prompt. Cursor movement across the
character moves too far.
xterm and urxvt on the same system with the same font show different behavior:
They render the symbol as a character which is two cells wide (horizontally
centered within that box). All operations (tab completion, character deletion,
cursor movement, linewrapping, ...) work as expected.
Debian is using glibc 2.24-9 with Unicode 9.0 EastAsianWidth.txt; this means
the glibc wcwidth returns 2 for \u26a1. I do not know if older versions of
glibc (<2.24-6) have shown the same behavior. EastAsianWidth.txt of Unicode 8.0
didn't contain \u26a1; it may be that it started when glibc switched to Unicode
9.0 (which it will on all distributions with 2.26).
I patched konsole_wcwidth.cpp to have its wcwidth implementation return 2 for
\u26a1. This fixes the behavior, but the symbol is now rendered left-aligned
within the two cells it's getting (it looks like lightning plus space
character). I do not know if it should be centered or left-aligned, but this
may be another issue (would prefer centered).
There seem to be other problems with konsole's wcwidth, cf.
https://eev.ee/blog/2015/09/12/dark-corners-of-unicode/ Wouldn't using the
system's wcwidth (if available?) be preferable? This might also give more
consistent behavior across the system.
--
You are receiving this mail because:
You are watching all bug changes.
