On 5/24/16 1:42 PM, Grisha Levit wrote:
> This was in en_US.UTF8. But I see now that the issue must be dependent on
> the underlying Unicode library support.
Not exactly. It's not specific to Unicode per se. It's the locale
definition and how the mb* functions and wcwidth() behave.
>
> For example this works fine on Ubuntu 16.04, but not on CentOS 7 or OSX
> 10.11. What I'm surprised about is that in either case the character *is*
> recognized as taking up 2 columns for the purposes of printing but not for
> the purposes of cursor movement during line editing.
That's not surprising. The line is a buffer of bytes, and editing is
performed on potentially-multibyte characters. If, for instance, mbrtowc
reports a sequence of bytes as composing an invalid multibyte character,
readline will treat them as a sequence of single-byte characters, and
output them to the terminal. If the terminal emulator chooses to display
those bytes as a Unicode character, readline can't know that.
It may also be a problem with the redisplay code. I can't tell yet.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU [email protected] http://cnswww.cns.cwru.edu/~chet/
_______________________________________________
Bug-readline mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/bug-readline
