On Thu, Sep 19, 2002 at 01:21:10AM -0400, [EMAIL PROTECTED] wrote: > Unless you believe that locales shouldnt specify encoding, and are > unhappy with their implementation (too global).
If an application wants to provide more detailed encoding configurations (such as editing multiple files in different windows, like Vim can do), that's fine, but it should always default to obeying the locale (which Vim does). The locale certainly shouldn't allow saying things like "use UTF-8 for the terminal and EUC-JP for files", since that's far more complicated. (What do you use if you're formatting from stdin? It might be either.) > Also, using them isnt necessarily future-proof. For example you > generally wouldnt want to use the "mb" functions if all your > output was ucs-4 wide characters. (are there any utf-32 locales?) (assuming s/utf-32/ucs-4/; they're close, but not synonymous) No, but if there was, then the "multibyte" encoding would be UCS-4, and the mb* functions would treat them as such--wide characters and locale characters would contain the same binary data, mblen() would always return 0 or 4, and converting wc<->mb would be a null op. (Ignoring endianness, and all of the other numerous reasons you don't use UCS-4 as a locale encoding.) > >Why does Mr. Lazy even care about ancient non-__STDC_ISO_10646__ systems? > >He's lazy! :) > > Taking this argument to its logical conclusion; why care about > those using legacy(non-utf8) encodings... My personal opinion is that there's been plenty of time for systems to support __STDC_ISO_10646__; the fact that almost all systems do is evidence that it's been long enough, and I don't want to go out of my way to support systems that are lagging so far behind. However, there are a lot more people who still, for one reason or another, can't use UTF-8, so there's a lot more reason to support legacy encodings. -- Glenn Maynard -- Linux-UTF8: i18n of Linux on all levels Archive: http://mail.nl.linux.org/linux-utf8/
