Re: SUGGESTION: Mule-on-Windows, full Unicode support XEmacs
first, let me say that i *REALLY* appreciate your work testing the program for
me. it's obviously hard to create programs in a vacuum, and esp. in this case
when i do all my day-to-day work in English!
Matej Mihelic wrote:
----- Original Message -----
From: "Ben Wing" <ben(a)666.com>
To: "Matej Mihelic" <matej(a)neosys.xrs.si>
Sent: Sunday, September 02, 2001 2:49 AM
Subject: Re: SUGGESTION: Mule-on-Windows, full Unicode support XEmacs
MM>> XEmacs is now hooked into Windows-only API for
MM>> Unicode. Could this be extended to include and use
MM>> the WinAPI built-in functions for translating
MM>> Unicode to ANSI and Unicode to OEM (or Unicode <->
MM>> ANSI <-> OEM).
MM>> ...
MM>> Perhaps I assume wrong, but wouldn't such coding systems
MM>> read and write transparently Unicode buffers into whatever
MM>> codepage the user's Windows installation defines as ANSI
MM>> or OEM codepage ? For me, since I use Eastern Europe /
MM>> Slovenian locale, this
BW> i already do all of this and more. [well, i don't do
BW> OEM support, but it's not needed.]
Hmmm... Don't Windows command line utilities run in OEM
codepage? Shouldn't then the default process-coding-system
for MSWindows be an OEM codepage?
are you sure? the only docs i can find about where oem codepages are used say
they're used with the ansi versions of console API's, e.g. WriteConsoleA().
which utilities are you referring to?
BW> in my latest workspaces, you should be able to use
BW> Eastern European by default with no setup needed --
BW> just switch to the appropriate keyboard layout. [same
BW> for Cyrillic, modulo the "Russian C-x problem"]
BW>
BW> the coding system `mswindows-multibyte' converts from
BW> Windows ANSI in the the system-default code page. [hmm,
BW> i should add a parameter to specify the code page]
Great. I was able to read, write and convert files from ANSI,
ISO8859-2 and UNICODE.
I had the following problems - please, keep in mind that I
am not an XEmacs expert, so my setup and my mistakes could
be the reason for my problems:
- I have not found a way to setup the coding systems to
work transparently using "default" coding systems.
could you explain what you expect to work and isn't working?
- I had to manually set the coding system for each command
because I there was a mistake the files would get corrupted
without any warning - all extended characters were
replaced by tilde character in resulting files.
There really should be a warning if the resulting
conversion will lose information.
yes, this is unfortunately a long-standing problem that no one so far has had
time to work on. i agree it's pretty bad, though, and i'll make sure it's
reasonably high priority. [the idea actually would be to signal an error when
information is getting lost, and prompt the user for a coding system; after
that, the user has to explicitly say "yes" if information will be lost.]
- EOL type detection doesn't detect DOS line encoding
automatically/correctly.
hmmm ... it seems ok for me. can you be specific? is it only with unicode
files?
- I tried to open two different files from my C: root.
Here are the resulting messages XEmacs:
c:\tmp2.txt and c:\tmp.txt are the same file (c:\)
c:\t.txt and c:\tmp.txt are the same file (c:\)
ok, i can reproduce and i'll fix.
- There seems to be a problem with selecting fonts.
For instance: If I set a default face font to Lucida
Console it will be ignored:
(set-face-font 'default "Lucida Console:Regular:12::Central European")
However EastEuropean characters in all buffers _will be_
displayed in this font. I have attached a screen
snapshot.
well, you shouldn't be specifying a charset. if you do, only characters in that
charset match; others will end up using the fallback values. that's why you see
what you do. instead try
(set-face-font 'default "Lucida Console:Regular:12::")
you can specify a bunch of different fonts to try one after the other by giving
a list to set-face-font. in that list, you could include font names qualified
with a charset if you wanted to set the font for only that charset and make
other characters the check and use a different charset.
- There is a problem with Unicode text files created with
XEmacs. If I create a Unicode text file using WordPad I
can open it in XEmacs. As soon as I save the file back to
disk the WordPad will not open it again.
The only difference is in a header:
C:\>comp t_wordpad.txt t_xemacs.txt
Comparing t_wordpad.txt and t_xemacs.txt...
Compare error at OFFSET 0
file1 = FF
file2 = 13
Compare error at OFFSET 1
file1 = FE
file2 = 30
All test were performed on a W2K-Pro SP2 with XEmacs running in a "vanilla"
configuration.
ok, i can reproduce and i'll fix.
OS: Windows_NT
XEmacs 21.5-b1 \"anise\" configured for `i586-pc-win32'.
Building XEmacs in \"E:\\xemacs-21.5\\nt\".
Using compiler \"cl -nologo -W3 -O2 -G5 -ML\".
Installing XEmacs in \"e:\\razno\\XEmacs\\XEmacs-21.5-b1\".
Package path is
\"~\\.xemacs;;e:\\razno\\xemacs\\site-packages;e:\\razno\\xemacs\\xemacs-packages\".
Compiling in support for Microsoft Windows native GUI.
--------------------------------------------------------------------
WARNING: Compiling without GTK support.
WARNING: As of xemacs-21.2-b44
WARNING: gtk-xemacs is not supported on MSWindows (mingw or msvc).
WARNING: Yes, we know that gtk has been ported to native MSWindows
WARNING: but XEmacs is not yet ready to use that port.
--------------------------------------------------------------------
Compiling in support for XPM images.
Compiling in support for GIF images.
Compiling in support for PNG images.
Compiling in support for TIFF images.
Compiling in support for JPEG images.
Compiling in support for X-Face message headers.
Compiling in support for toolbars.
Compiling in support for dialogs.
Compiling in support for widgets.
Compiling in support for native sounds.
Compiling in fast dired implementation.
--------------------------------------------------------------------------------
Name: XEmacs-Mule.tif
XEmacs-Mule.tif Type: TIFF Image (image/tiff)
Encoding: base64