8:06 p.m.
I have a new problem using the current cvs source code compiled with
Mule under native win32.
The Mule tests run ok (apart for the bug below). But whenever
I ask for example :
(split-char ?é) ;; here the char is eacute
I get some funny result: (chinese-sisheng 38).
Also, when I open a new file in 'Noconv' encoding mode (ie: should be
latin-1), if I type some accented characters and then I save the file,
the file is unreadable (contains ~ chars if I 'type' it on the
console). Next if I switch the encoding to MSW-MB and I write the file
again, then the chars are correct on the console, even if in the buffer
those chars are still reported to belong to some other encoding (by
asking (char-charset (char-after (point))) ) and displayed correctly.
The trick is that Gnus does not tolerate that the encoding is reported
wrong, it will split your message in as many parts as needed to
mime-send it.
I have tried to disable every single option I could (no optimization, no
KKCC, no UNION_TYPE etc.), every time making a distclean. No I wonder
where to look in the source code.
Let me know if I can help further in solving this problem.
Thanks in advance for your help,
--
Fabrice
------------------------------------------------------------------------------
This patch seems to be required (usually in lisp, you can't #'eq lists):
C:\Source\fptex\source.development\xemacs>diff -u tests\automated\mule-tests.el~
"tests\automated\mule-tests.el"
--- tests\automated\mule-tests.el~ Mon Jan 20 15:55:11 2003
+++ tests\automated\mule-tests.el Tue Jan 28 20:54:55 2003
＠＠ -336,14 +336,14 ＠＠
;; #### rewrite robustly, both assume that the tested implementation
;; uses the same algorithm as was used by the version current at time
;; this test was written
- (Assert (eq (charsets-in-region (point-min) (point-max))
+ (Assert (equal (charsets-in-region (point-min) (point-max))
'(korean-ksc5601 chinese-big5-1 chinese-gb2312
japanese-jisx0212 katakana-jisx0201 japanese-jisx0208
vietnamese-viscii-lower thai-xtis cyrillic-iso8859-5
hebrew-iso8859-8 greek-iso8859-7 latin-iso8859-1
latin-iso8859-2 arabic-2-column arabic-1-column
ethiopic ascii)))
- (Assert (eq (charsets-in-string (buffer-substring (point-min) (point-max)))
+ (Assert (equal (charsets-in-string (buffer-substring (point-min) (point-max)))
'(korean-ksc5601 chinese-big5-1 chinese-gb2312
japanese-jisx0212 katakana-jisx0201 japanese-jisx0208
vietnamese-viscii-lower thai-xtis cyrillic-iso8859-5
------------------------------------------------------------------------------
XEmacs/Installation file (contrarily to what is stated, I have switched
the compilation options to -Od instead of -O2, so there are no
optimization in the code)
OS version:
Microsoft Windows XP [Version 5.1.2600]
OS: Windows_NT
XEmacs 21.5 "burdock" (+CVS-20030126) configured for `i586-pc-win32'.
Building XEmacs using "nmake".
Building XEmacs using make flags " ".
Building XEmacs in "C:\\Source\\fptex\\source.development\\xemacs\\nt".
Using compiler "＠cl -nologo -W3 -DSTRICT -Od -G6 -Gr -MD".
Installing XEmacs in "c:\\Program Files\\XEmacs\\XEmacs-21.5".
Package path is "~\\.xemacs;;c:\\Program Files\\XEmacs\\site-packages;c:\\Program
Files\\XEmacs\\mule-packages;c:\\Program Files\\XEmacs\\xemacs-packages".
Compiling in support for Microsoft Windows native GUI.
Compiling in international (MULE) support.
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 GZIP compression/decompression.
Compiling in support for toolbars.
Compiling in support for dialogs.
Compiling in support for widgets.
Compiling in support for native sounds.
Using portable dumper.
Using system malloc.
Using DLL version of C runtime library.
Compiling with optimization.
------------------------------------------------------------------------------
12:26 p.m.
hmm, i'll look into this.
chinese-sisheng 38 is indeed an e-acute.
when i copied-and-pasted your example, i got
(split-char ?é)
(latin-iso8859-4 105)
but this doesn't prove anything. the question is, where did the e-acute come
from? if this is from unicode conversion, maybe the language list is messed up.
stephen, any insights? you're the latin-unity guy.
----- Original Message -----
From: "Fabrice Popineau" <Fabrice.Popineau(a)supelec.fr>
To: "xemacs-beta" <xemacs-beta(a)xemacs.org>; "xemacs-nt"
<xemacs-nt(a)xemacs.org>
Sent: Tuesday, January 28, 2003 1:06 PM
Subject: Mule, win32 native, current cvs
I have a new problem using the current cvs source code compiled with
Mule under native win32.
The Mule tests run ok (apart for the bug below). But whenever
I ask for example :
(split-char ?é) ;; here the char is eacute
I get some funny result: (chinese-sisheng 38).
Also, when I open a new file in 'Noconv' encoding mode (ie: should be
latin-1), if I type some accented characters and then I save the file,
the file is unreadable (contains ~ chars if I 'type' it on the
console). Next if I switch the encoding to MSW-MB and I write the file
again, then the chars are correct on the console, even if in the buffer
those chars are still reported to belong to some other encoding (by
asking (char-charset (char-after (point))) ) and displayed correctly.
The trick is that Gnus does not tolerate that the encoding is reported
wrong, it will split your message in as many parts as needed to
mime-send it.
I have tried to disable every single option I could (no optimization, no
KKCC, no UNION_TYPE etc.), every time making a distclean. No I wonder
where to look in the source code.
Let me know if I can help further in solving this problem.
Thanks in advance for your help,
--
Fabrice
------------------------------------------------------------------------------
This patch seems to be required (usually in lisp, you can't #'eq lists):
C:\Source\fptex\source.development\xemacs>diff -u tests\automated\mule-tests.el~
"tests\automated\mule-tests.el"
--- tests\automated\mule-tests.el~ Mon Jan 20 15:55:11 2003
+++ tests\automated\mule-tests.el Tue Jan 28 20:54:55 2003
＠＠ -336,14 +336,14 ＠＠
;; #### rewrite robustly, both assume that the tested implementation
;; uses the same algorithm as was used by the version current at time
;; this test was written
- (Assert (eq (charsets-in-region (point-min) (point-max))
+ (Assert (equal (charsets-in-region (point-min) (point-max))
'(korean-ksc5601 chinese-big5-1 chinese-gb2312
japanese-jisx0212 katakana-jisx0201 japanese-jisx0208
vietnamese-viscii-lower thai-xtis cyrillic-iso8859-5
hebrew-iso8859-8 greek-iso8859-7 latin-iso8859-1
latin-iso8859-2 arabic-2-column arabic-1-column
ethiopic ascii)))
- (Assert (eq (charsets-in-string (buffer-substring (point-min) (point-max)))
+ (Assert (equal (charsets-in-string (buffer-substring (point-min)
(point-max)))
'(korean-ksc5601 chinese-big5-1 chinese-gb2312
japanese-jisx0212 katakana-jisx0201 japanese-jisx0208
vietnamese-viscii-lower thai-xtis cyrillic-iso8859-5
------------------------------------------------------------------------------
XEmacs/Installation file (contrarily to what is stated, I have switched
the compilation options to -Od instead of -O2, so there are no
optimization in the code)
OS version:
Microsoft Windows XP [Version 5.1.2600]
OS: Windows_NT
XEmacs 21.5 "burdock" (+CVS-20030126) configured for `i586-pc-win32'.
Building XEmacs using "nmake".
Building XEmacs using make flags " ".
Building XEmacs in "C:\\Source\\fptex\\source.development\\xemacs\\nt".
Using compiler "＠cl -nologo -W3 -DSTRICT -Od -G6 -Gr -MD".
Installing XEmacs in "c:\\Program Files\\XEmacs\\XEmacs-21.5".
Package path is "~\\.xemacs;;c:\\Program
Files\\XEmacs\\site-packages;c:\\Program
Files\\XEmacs\\mule-packages;c:\\Program Files\\XEmacs\\xemacs-packages".
Compiling in support for Microsoft Windows native GUI.
Compiling in international (MULE) support.
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 GZIP compression/decompression.
Compiling in support for toolbars.
Compiling in support for dialogs.
Compiling in support for widgets.
Compiling in support for native sounds.
Using portable dumper.
Using system malloc.
Using DLL version of C runtime library.
Compiling with optimization.
------------------------------------------------------------------------------
2:04 p.m.
>>>> "Ben" == Ben Wing <ben(a)666.com>
writes:
Ben> but this doesn't prove anything. the question is, where did
Ben> the e-acute come from? if this is from unicode conversion,
Ben> maybe the language list is messed up.
My guess is that it's the language list, but it could be anywhere
because of how screwed up Mule has historically been about handling
environments.
I would start by pruning the list of character sets loaded by default.
chinese-sisheng is presumably of mostly historical interest now. Only
linguists and Chinese educators could possibly be interested in it,
and they presumably would prefer to use Unicode or a Chinese character
set that includes hanzi. IPA is another that should go, if it has a
non-Unicode encoding. The CNS coding systems are basically unused.
Really the only languages that should have multiple non-Unicode coding
systems loaded by default are Japanese ("hello, foot, meet my friend
bullet") and Russian (KOI8 is a Cold War relic, I guess, but unlike
ISO 2022 and EUC the ISO standard is basically not accepted in
Cyrillic countries).
Ben> stephen, any insights? you're the latin-unity guy.
I didn't know anything about chinese-sisheng; latin-unity has nothing
to do with that. ... Hm, still doesn't, that's not a latin alphabet,
it's a phonetic alphabet for Chinese that happens to include some
latin characters.
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
2:58 p.m.
My guess is that it's the language list, but it could be
anywhere
because of how screwed up Mule has historically been about handling
environments.
I can use Gnus/XEmacs/Mule with less problems than ever apparently :
;; Some test made in the *scratch* buffer
éàçèûîöë€
(mm-find-charset-region 395 404)
(latin-iso8859-15 latin-iso8859-1)
;; end of test
I think this patch :
2002-11-01 Ilpo Nyyssönen <iny(a)iki.fi>
* mule/mule-cmds.el (finish-set-language-environment): Fix for
call to set-language-unicode-precedence-list.
fixed it up.
Fabrice
8121
days inactive
8137
days old
3 comments
3 participants
participants (3)
-
Ben Wing -
Fabrice Popineau -
Stephen J. Turnbull