Re: multibyte backwarddeletechar

[Geoff Wing <gcw@xxxxxxx>]

Clint Adams <clint@xxxxxxx> typed:
:I don't intend to commit this patch as-is.
:This causes backward-delete-char to delete entire
:multibyte characters (valid in the current locale)
:rather than their component octets.

Except that the ZLE refresh code can't handle it.  The code
only sees single characters and won't pass multibyte characters
through to the underlying terminal properly.

Background info for everyone: terminal emulators (I say "terminal
emulators" because I don't know of any terminals which can handle
multibyte glyphs but there may be some around) need multibyte glyphs
to be passed through atomically (considering only the character stream)
otherwise the terminal emulator can't know what constitutes part of
a glyph and what doesn't.  In common multibyte languages, this means
that pairs of characters (representing one glyph two characters wide)
must be passed through in sequence.

The ZLE refresh code quite happily writes the second half of multibyte
glyphs through out of context (i.e. without the first half) which would
corrupt terminal emulator displays.

My first thought is whether it is meaningful to use multibyte glyphs
on the command line.  And it may well be if, say, people name files using
multibyte glyphs and other programs (e.g. ls) display those names.
My second is whether we truly want to handle multibyte glyphs.  I don't
think minihacks will work.  It may be a major overhaul.  Not just the ZLE
refresh code would need updating but other areas too.  Of course, it
may not be as much work as I think but would definitely need some
discussion about what should and should not be handled.

Regards,
-- 
Geoff Wing | gcw@xxxxxxxxx | gcw@xxxxxxxx | gcw@xxxxxxx