Re: PATCH: assume "enhanced goodness" when --multibyte-enable

[Peter Stephenson <pws@csr.com>]

Oliver Kiddle wrote:
> Peter wrote:
> > In utils.c we don't enable the full multibyte code for converting
> > characters unless __STDC_ISO_10646__ is turned on.  However,
> everywhere
> > in zle we simply trust that if --multibyte-enable is turned on
> > everything just works.  That includes wctomb(), which is all we need
> > for character conversion.
> 
> This doesn't make sense to me. With MULTIBYTE_SUPPORT enabled are you
> just assuming that wchar_t is UCS-4 everywhere?

ish...

> I don't understand how that'll work if you have a system which has
> perfectly good multibyte support but uses some other encoding for
> wchar_t.

It might well not, but up to now I've been assuming we need to know how
to convert it.  --enable-multibyte just says "go ahead and assume this
works".  Unless we can probe for what to do with a wchar_t I've been
assuming we're kind of stuck.

However, the assumptions we rely on are a bit different in the code for
converting Unicode characters and in the reset of zle, so quite likely
they shouldn't be tied...

In converting \U/\u sequences, as you say, we really need fully paid up
UCS-4.

In the reset of zle, we need wchar_t to be an integer which overlaps
with ASCII in positions 0 to 127, and we only need that in some places.
(A lot of the time we can work on the pre-converted multibyte string,
since that *must* have ASCII has a subset, and it's probably possible to
do that everywhere by additional conversions.)  I don't think it
necessarily has to be exactly UCS-4 and most of the time it probably
works if it isn't.  So maybe the change is wrong.

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK                          Tel: +44 (0)1223 692070


This message has been scanned for viruses by BlackSpider MailControl - www.blackspider.com