development release newLISP v.9.2.6

[Lutz]

The newlisp core will stay as it is with different makefiles for utf8 and non-utf-8. utf-8 cannot be included in all versions, because some platforms don't offer the support for the wchar data type (unicode wide characters).



So for Linux and BSD and other UNIX things basically will stay the same. Win32 will be shipped as non-utf-8 as before, and Mac OS X will be shipped utf-8 as before.



The only change will be that the guiserver will switch to utf-8 if newLISP is running utf-8, and that it can be overwritten using gs:set-utf8.



For Win32 utf-8 compiled newlisp.exe and newlisp.dll will be put in a separate directory.



Lutz

[newBert]

NewLISP 9.2.6 now works on my machine, but I must just change all my accented characters ... and:

When I double-clic on a NewLISP script I get only a black DOS-console ... or nothing.

... because NewLISP v.9.2.6 doesn't like accented characters in file names. So I must modify all my file names too.



But:

The newlisp core will stay as it is with different makefiles for utf8 and non-utf-8. utf-8 cannot be included in all versions, because some platforms don't offer the support for the wchar data type (unicode wide characters).



(...)



For Win32 utf-8 compiled newlisp.exe and newlisp.dll will be put in a separate directory.



Lutz

So I'll wait a moment before modifying anything at all :-)

[Lutz]

Using UTF-8 on Windows may only make sense if all your other text processing tools use UTF-8 too, especially any editors you are using.



So for Windows it seems to be better to stay without UTF-8, but you always can enable it by just replacing the newlisp.exe. Guisierver will adapt automatically to it.



Lutz

[Dmi]

It seems that on Windows, although it can support UTF-8, most applications are written to use the ISO/IEC-8859 one-byte-length character set, where the accented, umlaut and other special characters are encoded in one-byte values > 128. I believe even Russian language or Hebrew language Windows uses ISO 88xx one-byte-length character sets. Perhaps some Russian and Israeli users can confirm this.

Rissian Windows 9x/2k/XP uses one byte Windows-1251 (mostly for windows apps) mixed with one byte CP866 (file system names and console apps) mixed with two byte utf-8 (Registry and some internals in Win2k/XP).

ISO8859-5 isn't wide spreaded in Russia, but there are a few...



Compatibility with Win98 (for console scripting only, GS and newlisp-edit aren't needed) and compatibility with one-byte encodings is much sufficient for business apps (the enterprise automatisation is arhaic sometimes ;-)



Support for one-byte encodings in Unix is too mandatory for the business, because many applications are related to interacting with windows and many applications are related to interacting with commercially supported transaction systems, that are based on one byte encodings.



In the other hand - to have a switchable utf-8/single byte behavior would be nice.

But what about simple proper locale supporting? I.e., usage of OS libraries for all locale-related stuff?

The question is: what for the support for utf-8 in a system which haven't a locale libs at all?