bug in completion/expansion of files with LANG=C

[Wayne Davison <wayned@xxxxxxxxxxxxxxxxxxxxx>]

I have a file I named hmm.\303\244 (which appears to be a lower-case a
with two dots over it in UTF-8).  However, if I have LANG=C, zsh refuses
to complete the filename in any form on my terminal -- it just stops
after the period (this is with MULTIBYTE_SUPPORT enabled).  If I set
LANG=en_US.UTF-8 (or even en_US.iso88591) the filename will start to
complete (though it displays wrong when being edited on my system that
only supports en_US.iso88591, but I expected that).  When I use a zsh
that has MULTIBYTE_SUPPORT disabled, the name completes and causes the
normal editing-output glitches, as you'd expect.

What should zsh do with characters that are outside the current
character set?  Display them as \M-* values?  A zsh without multibyte
support displays the name as hmm-\M-C\M-$ when being listed by the
completion system, but inserts the name into the command-line as literal
characters.  Perhaps a multibyte-enabled zsh should edit these illegal
characters on the command-line as 4-byte-wide \M-* values; and go back
to displaying them in completion lists that way too?

One more oddity I noticed:

Even on my Ubuntu Linux system that has en_US.UTF-8 and en_GB.UTF-8
support (at least, it lists those when completing "export LANG="),
editing a command-line that included the hmm.\303\244 name never worked
quite right with any setting of LANG.  For instance, using Ctrl-A to get
to the start of the line moved to the right position on the screen, but
pressing Ctrl-F to go forward output the wrong character in each
position (one character too far to the right).  I'm starting to debug
why this is happening...

..wayne..