Zsh Mailing List Archive
Messages sorted by:
Re: Latest CVS + ZLE_UNICODE_SUPPORT on RHEL3
- X-seq: zsh-workers 20835
- From: Borzenkov Andrey <arvidjaar@xxxxxxxxxx>
- To: <zsh-workers@xxxxxxxxxx>
- Subject: Re: Latest CVS + ZLE_UNICODE_SUPPORT on RHEL3
- Date: Mon, 21 Feb 2005 16:37:00 +0300
- In-reply-to: <E1D3Ddp-000JDB-00.arvidjaar-mail-ru@xxxxxxxxxxx>
- Mailing-list: contact zsh-workers-help@xxxxxxxxxx; run by ezmlm
Пн, 21.02.2005 17:30:25 you wrote:
>> Bart Schaefer wrote:
>> I tried defining ZLE_UNICODE_SUPPORT and building on RHEL3 (really CentOS,
>> but that shouldn't matter)
> Generally speaking, I'm not that suprised, since there are large numbers
> of odds and ends still to clear up (I haven't tried turning it on yet).
> > and the build died on a syntax error in zle.h
> > (apparently the "int_t" typedef does not exist?).
> That should have been wint_t. That's guaranteed to hold either a
> wchar_t or a WEOF.
> Clint and I have added various type and functions like this without there
> being any tests in configure: this is one reason we're currently relying
> on the compiler offering support.
BTW wctype.h was missing
If we want to relax that assumption
> later, we'll probably have to work out what to do if wchar_t is defined
> and wint_t isn't, etc. I suppose the answer in this case is probably
> just stick with wchar_t. But that's all Zukunftsmusik.
I played with this patch over weekend (with fixed wint_t and couple of other obvious mismatches). So far I was not able to make zsh work with ZLE_UNICODE_SUPPORT.
The problem seems to be that currently zle returns to zsh array of wchar_t; and zsh of course has no idea what to do with it (and treats it as array of char anyway). I started to attempt to fix it but then I realized I do not know (and there is nothing in patch) what was intended:
- convert the whole zsh to operate on wchar_t instead of char
- convert wchar_t to something else (mbchar back? UTF-8?) before passing it to main zsh code.
I would rather prefer the latter and make it UTF-8. This retains maximum compatibility, allows keep string processing functions and allows definition of character constants (zsh is full of them). It is not possible to portably define constant with wchar_t because run-time locale is not neccessarily the same as compile-time locale (consider ASCII vs EBCDIC).
BTW I finally switched to UTF-8 and stock zsh (without ZLE_UNICODE_SUPPORT enabled) displayes garbage instead of Russian file names and crashes when I attempt to complete them. Is it expected? IIRC there were some patches to allow at least passing multibyte through.
PS Would somebody kindly look into the issue with mail.ru addresses? I can subscribe from this address and get list messages but apparently nothing I post using "arvidjaar (at) mail dot ru" ever gets posted. Thank you.
www.newmail.ru -- бесплатная почта, бесплатный хостинг.
Messages sorted by: