String len() is used as width

Description of the problem

Looking at the code I see many lines where the len() of a string is used for the (terminal-)width of this string. But there are codepoints with width 0 and 2. For example “o” with an arrow above: o⃗ (U+006F U+20D7). The U+20D7 arrow has width 0. Or 😼 (U+1f63c): this codepoint has width 2. If one enters or uses such codepoints the whole layout is “out of sync”.

Example

Here is an example with demo.py and the form widgets: Before: and after:

Question

Are there any plans to support wcwidth?

[luchr]

Vim is (in this context) not suitable (as width test, etc.) because for an editor there are other requirements than for a terminal emulator. Fun fact: Gtk-Vim can render some(!) combining characters correctly because of this patch from me 😃

Until the terminal persons reach some “consensus” how to handle ZWJ and Var-Selectors etc. and adapt their terminal emulators, I think your “size of char test” is an acceptable approximation (and fast because no ECG-segmentation is performed). [The other option “to program for all the different terminal emulator behaviours and/or place the cursor explicitly after every ZWJ and Var-Selectors” is toooo much work.]

So let’s close, or?

[zerowhybr]

I am also experiencing this problem with ANSI color codes. I believe the library is considering color sequences as part of terminal length. Maybe this can be helpful for fixing this issue, it is a fix that another project used for this very same problem: Tabulate source code