Date: Sun, 7 May 2000 02:50:20 +0900 (JST) From: Hajimu UMEMOTO (=?ISO-2022-JP?B?GyRCR19LXBsoQiA=?= =?ISO-2022-JP?B?GyRCSCUbKEI=?=) <ume@mahoroba.org> To: obrien@FreeBSD.ORG Cc: i18n@FreeBSD.ORG Subject: Re: i18n /bin/[t]csh Message-ID: <200005061750.e46HoKF91598@peace.mahoroba.org> In-Reply-To: <20000506102746.C1545@dragon.nuxi.com> References: <vqc4s8cxcwd.fsf@silvia.hip.berkeley.edu> <20000506232135A.ume@mahoroba.org> <20000506102746.C1545@dragon.nuxi.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>>>>> On Sat, 6 May 2000 10:27:46 -0700 >>>>> "David O'Brien" <obrien@FreeBSD.ORG> said: obrien> On Sat, May 06, 2000 at 11:21:35PM +0900, Hajimu UMEMOTO wrote: > No. It is still limited in non-multibyte by default. To handle > multibyte, we still need to add more defines. As you know, tcsh has > multibyte support. But, it influence to non-multibyte or non-Japanese > multibyte is not known. So, it is disabled by default. obrien> How about giveing me some patches to add the other defines. Then calling obrien> for -CURRENT to try it out. Then maybe we can determine if it is safe or obrien> not. I believe you know it, because you did commit to be able to build Kanji enabled tcsh. :-) While WANT_KANJI=no, binary distribution will not be able to handle multibyte and, we may recompile tcsh from source. Defining `KANJI' and `DSPMBYTES' makes Japanese happy. But, the influence for non-Japenese is unknown. To have really i18n tcsh, we should verify the behavior of `KANJI' and `DSPMBYTES' defines for single-byte locales and multi-bytes locales. -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@bisd.hitachi.co.jp ume@FreeBSD.org http://www.imasy.org/~ume/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-i18n" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200005061750.e46HoKF91598>