Re: SUGGESTION: Mule-on-Windows, full Unicode support XEmacs

Hello. BW>first, let me say that i *REALLY* appreciate your work BW>testing the program for me. it's obviously hard to BW>create programs in a vacuum, and esp. in this case when BW>i do all my day-to-day work in English! Well, I work in software development. I know just how much faster and "complete" the debugging process is if different people, especially users, participate in it. A slightly different behavior and usage pattern of a user when compared to the programmer can make a lot of difference. MM>> Hmmm... Don't Windows command line utilities run MM>> in OEM codepage? Shouldn't then the default MM>> process-coding-system for MSWindows be an OEM MM>> codepage? BW>are you sure? the only docs i can find about where BW>oem codepages are used say they're used with the ansi BW>versions of console API's, e.g. WriteConsoleA(). BW>which utilities are you referring to? Well for instance COMMAND prompt will produce OEM codepage. I am talking about DIR and similar commands. It's logical since before the Windows are started (Win9x) there are no "Windows codepages". So BATCH files have to be written in OEM codepage. The console windows (CMD or COMMAND) display characters in OEM codepage not in ANSI. The following examples will demonstrate this: - Using a EastEuropen version of Windows95 (Slovenian locale): DIR *.* > tmp.txt NOTEPAD tmp.txt ... the tmp.txt will contain OEM characters - EDIT.COM command - any Windows version including W2K: EDIT test.txt ... write some "extended" characters. NOTEPAD test.txt ... OEM characters are unreadable. The common consensus (before W2K and WinME) was that any file written to disk should be in OEM codepage. That was because any DOS program - even DOS Word-processor - would not be able to display ANSI codepage. BTW: I would suggest using a VM emulator like VirtualPC or VMWare for testing. It amazing how much time you can save by quickly testing the code on a multiple platforms and locale environments at the same time. MM>> - I have not found a way to setup the coding systems MM>> to work transparently using "default" coding systems. BW>could you explain what you expect to work and isn't BW>working? MM>> - EOL type detection doesn't detect DOS line encoding MM>> automatically/correctly. BW>hmmm ... it seems ok for me. can you be specific? is BW>it only with unicode files? I'll do more testing. I guess my configuration must have been wrong. It will take me a few days :(. MM>> - There seems to be a problem with selecting fonts. MM>> For instance: If I set a default face font to Lucida MM>> Console it will be ignored: MM>> However EastEuropean characters in all buffers _will be_ MM>> displayed in this font. I have attached a screen MM>> snapshot. BW>well, you shouldn't be specifying a charset. if you BW>do, only characters in that charset match; others will BW>end up using the fallback values. that's why you see BW>(set-face-font 'default "Lucida Console:Regular:12::") :) It's logical. Thanks. -- Regards, MM.