This was in en_US.UTF8. But I see now that the issue must be dependent on the underlying Unicode library support.
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. READLINE_POINT is, however, properly adjusted (changing by 4 with each character movement). On Tue, May 24, 2016 at 8:58 AM, Chet Ramey <[email protected]> wrote: > On 5/24/16 2:05 AM, Grisha Levit wrote: > > Some wide characters (e.g. U+1F201 🈁) really mess up readline. For > > example, it treats it correctly as a wide character when pasted on the > line > > but then only moves the cursor one point when moving back through the > line. > > I haven't looked at this yet, but this is exactly what should happen when > you use a multibyte character that isn't valid in the current locale. > > -- > ``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
