9:21 a.m.
I'm looking for testers. There is a complete and fast implementation
in C of Unicode conversion, translations for almost all of the
standardly-defined charsets that load up automatically and
instantaneously at runtime, coding systems supporting the common
external representations of Unicode [utf-16, ucs-4, utf-8,
little-endian versions of utf-16 and ucs-4; utf-7 is sitting there
with abort[]s where the coding routines should go, just waiting for
somebody to implement], and a nice set of primitives for translating
characters<->codepoints and setting the priority lists used to control
codepoint->char lookup.
It's so far hooked into one place: the Windows IME. Currently I can
select the Japanese IME from the thing on my tray pad in the lower
right corner of the screen, and type Japanese into XEmacs, and you get
Japanese in XEmacs -- regardless of whether you set either your
current or global system locale to Japanese,and regardless of whether
you set your XEmacs lang env as Japanese. This should work for many
other languages, too -- Cyrillic, Chinese either Traditional or
Simplified, and many others, but YMMV. There may be some lurking
bugs (hardly surprising for something so raw).
To get at this, checkout using `ben-mule-21-5', NOT the simpler
*`mule-21-5'. For example
cvs -d :pserver:xemacs＠cvs.xemacs.org:/usr/CVSroot checkout -r ben-mule-21-5 \
xemacs
or you get the idea. the `-r ben-mule-21-5' is important.
I keep track of my progress in a file called README.ben-mule-21-5 in
the root directory of the source tree.
WARNING: Pdump might not work. Will be fixed rsn.
ben
8:13 p.m.
Hi Ben,
I am getting this, trying to build:
cd c:\Hacking\xemacs\xemacs-ben-mule-21-5\nt\
nmake /f xemacs.mak INSTALL_DIR="c:\Program
Files\XEmacs\XEmacs-$(XEMACS_VERSION_STRING)"
JPEG_DIR="c:\Hacking\libs4xemacs\jpeg-6b"
MAKEINFO="c:\Hacking\texinfo-4.0\makeinfo\makeinfo.exe"
PNG_DIR="c:\Hacking\libs4xemacs\libpng-1.0.2"
TIFF_DIR="c:\Hacking\libs4xemacs\tiff-v3.4" USE_PORTABLE_DUMPER="1"
XPM_DIR="c:\Hacking\libs4xemacs\xpm-3.4k"
ZLIB_DIR="c:\Hacking\libs4xemacs\zlib" all
Compilation started at Tue Aug 21 21:10:14 2001
Microsoft (R) Program Maintenance Utility Version 6.00.8168.0
Copyright (C) Microsoft Corp 1988-1998. All rights reserved.
WARNING: Compiling without dependency information.
Creating c:\Hacking\xemacs\xemacs-ben-mule-21-5\nt\..\lib-src\config.values
--------------------------------------------------------------------
OS version:
Microsoft Windows 2000 [Version 5.00.2195]
OS: Windows_NT
XEmacs 21.5-b2 \"artichoke\" configured for `i586-pc-win32'.
Building XEmacs in \"c:\\Hacking\\xemacs\\xemacs-ben-mule-21-5\\nt\".
Using compiler \"cl -nologo -W3 -Od -Zi -MDd\".
Installing XEmacs in \"c:\\Program Files\\XEmacs\\XEmacs-21.5-b2\".
Package path is \"~\\.xemacs;;c:\\Program Files\\XEmacs\\site-packages;c:\\Program
Files\\XEmacs\\xemacs-packages\".
Compiling in support for Microsoft Windows native GUI.
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.
Using minimal tagbits.
Using indexed lrecord implementation.
Using portable dumper.
Using system malloc.
Using DLL version of C runtime library
Compiling in extra debug checks. XEmacs will be slow!
--------------------------------------------------------------------
Does C:\Hacking\xemacs\xemacs-ben-mule-21-5\nt\..\src\config.h specify a file name
or directory name on the target
(F = file, D = directory)?
--
Adrian Aichner
mailto:adrian＠xemacs.org
http://www.xemacs.org/
8:51 p.m.
New subject: Please check out my new, Mule-on-Windows, full Unicode support XEmacs!
ms brain death.
it's fixed now.
Adrian Aichner wrote:
Hi Ben,
I am getting this, trying to build:
cd c:\Hacking\xemacs\xemacs-ben-mule-21-5\nt\
nmake /f xemacs.mak INSTALL_DIR="c:\Program
Files\XEmacs\XEmacs-$(XEMACS_VERSION_STRING)"
JPEG_DIR="c:\Hacking\libs4xemacs\jpeg-6b"
MAKEINFO="c:\Hacking\texinfo-4.0\makeinfo\makeinfo.exe"
PNG_DIR="c:\Hacking\libs4xemacs\libpng-1.0.2"
TIFF_DIR="c:\Hacking\libs4xemacs\tiff-v3.4" USE_PORTABLE_DUMPER="1"
XPM_DIR="c:\Hacking\libs4xemacs\xpm-3.4k"
ZLIB_DIR="c:\Hacking\libs4xemacs\zlib" all
Compilation started at Tue Aug 21 21:10:14 2001
Microsoft (R) Program Maintenance Utility Version 6.00.8168.0
Copyright (C) Microsoft Corp 1988-1998. All rights reserved.
WARNING: Compiling without dependency information.
Creating c:\Hacking\xemacs\xemacs-ben-mule-21-5\nt\..\lib-src\config.values
--------------------------------------------------------------------
OS version:
Microsoft Windows 2000 [Version 5.00.2195]
OS: Windows_NT
XEmacs 21.5-b2 \"artichoke\" configured for `i586-pc-win32'.
Building XEmacs in \"c:\\Hacking\\xemacs\\xemacs-ben-mule-21-5\\nt\".
Using compiler \"cl -nologo -W3 -Od -Zi -MDd\".
Installing XEmacs in \"c:\\Program Files\\XEmacs\\XEmacs-21.5-b2\".
Package path is \"~\\.xemacs;;c:\\Program Files\\XEmacs\\site-packages;c:\\Program
Files\\XEmacs\\xemacs-packages\".
Compiling in support for Microsoft Windows native GUI.
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.
Using minimal tagbits.
Using indexed lrecord implementation.
Using portable dumper.
Using system malloc.
Using DLL version of C runtime library
Compiling in extra debug checks. XEmacs will be slow!
--------------------------------------------------------------------
Does C:\Hacking\xemacs\xemacs-ben-mule-21-5\nt\..\src\config.h specify a file name
or directory name on the target
(F = file, D = directory)?
--
Adrian Aichner
mailto:adrian＠xemacs.org
http://www.xemacs.org/
4:31 a.m.
On Tue, 21 Aug 2001, Ben Wing wrote:
I'm looking for testers. There is a complete and fast
implementation
in C of Unicode conversion, translations for almost all of the
standardly-defined charsets that load up automatically and
instantaneously at runtime, coding systems supporting the common
external representations of Unicode [utf-16, ucs-4, utf-8,
little-endian versions of utf-16 and ucs-4; utf-7 is sitting there
with abort[]s where the coding routines should go, just waiting for
somebody to implement], and a nice set of primitives for translating
characters<->codepoints and setting the priority lists used to control
codepoint->char lookup.
[...]
Ben, the build fails for me with a segfault in temacs. I made a few
changes to make it compile at all under my Linux installation; the diff
against CVS is attached.
The various bits and pieces of output, including the build logs and the
gdb backtrace of the error, are included. If I can do anything further
to assist in the testing, let me know.
Oh, it's worth noting that I bumped the beta version up to 200 for this
testing; I didn't want to tromp my working XEmacs when I installed... :)
One point of note, at a user level, is that you seem to define the
coding system `utf8'. Gnus, the one real user of UTF-8 coding that I
know of, looks for coding systems named either `mule-utf-8' or `utf-8'.
It would be good to ensure that, at the least, XEmacs and GNU Emacs were
in sync on this; I believe (but can't verify) that the `utf-8' style is
used there...
So, the differences between the version I used, which builds as far as
temacs, and your branch in CVS:
The Installation file:
The output of the make process:
The gdb output showing the stack when the failure occurred:
Daniel
--
I read about an Eskimo hunter who asked the local missionary priest, "If I did
not know about God and sin, would I go to hell? 'No,' said the priest, 'not
if
you did not know.' 'Then why,' asked the Eskimo earnestly, 'did you tell
me?
-- Annie Dillard
9:36 a.m.
----- Original Message -----
From: "Ben Wing" <ben(a)666.com>
To: "XEmacs MULE" <xemacs-mule(a)xemacs.org>; "XEmacs NT List"
<xemacs-nt(a)xemacs.org>; "XEmacs beta list" <xemacs-beta(a)xemacs.org>
Sent: Tuesday, August 21, 2001 10:21 AM
Subject: Please check out my new, Mule-on-Windows, full Unicode support XEmacs!
Almost any operations regarding network drive will GPF XEmacs instantly.
Example of a GPF producing command (XEmacs was started with --vanilla option):
(dired "\\\\tau\\e\$\\")
Unfortunately the debug window is closed so fast, that I am unable to capture the output.
All I was able to do in that time was to snapshot the picture of the window. See
attachment.
BTW: I would really appreciate if someone would help me configure the XEmacs 21.5 for
CP1250 and CP852 support. Otherwise I can only do minimal testing.
*** Installation Information
OS version:
Microsoft Windows 2000 [Version 5.00.2195]
OS: Windows_NT
XEmacs 21.5-b2 \"artichoke\" configured for `i586-pc-win32'.
Building XEmacs in \"W:\\xemacs-21.5\\nt\".
Using compiler \"cl -nologo -W3 -O2 -G5 -ML\".
Installing XEmacs in \"e:\\razno\\XEmacs\\XEmacs-21.5-b2-mule\".
Package path is
\"~\\.xemacs;;e:\\razno\\xemacs\\site-packages;e:\\razno\\xemacs\\mule-packages;e:\\razno\\xemacs\\xemacs-packages\".
Compiling in support for Microsoft Windows native GUI.
Compiling in MULE.
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.
11:20 a.m.
>>>> "Matej" == Matej Mihelic
<matej(a)neosys.xrs.si> writes:
Hi Matej, Ben,
I see the same:
Fatal error: assertion failed, file
c:\Hacking\xemacs\xemacs-ben-mule-21-5\nt\..\src\dired-msw.c, line 418, ei5ptr[ei5] >=
0x20 && ei5ptr[ei5] < 0x7F
Call Stack:
NTDLL! 77fa018c()
mswindows_format_file(Win32_file * 0x023f5000, int 0, int 1) line 418 + 168 bytes
Fmswindows_insert_directory(long 37530356, long 37460292, long 28385284, long 28385308)
line 580 + 25 bytes
Ffuncall(int 5, long * 0x0082c7ac) line 3488 + 168 bytes
Fapply(int 2, long * 0x0082c89c) line 3764 + 13 bytes
Ffuncall(int 3, long * 0x0082c898) line 3509 + 14 bytes
execute_optimized_program(const unsigned char * 0x02327d10, int 5, long * 0x01f02190) line
744 + 16 bytes
funcall_compiled_function(long 36804160, int 5, long * 0x0082cb8c) line 516 + 53 bytes
Ffuncall(int 6, long * 0x0082cb88) line 3523 + 17 bytes
call5(long 36872316, long 28580468, long 37530356, long 37460292, long 28385284, long
28385308) line 4215 + 11 bytes
Fmswindows_insert_directory(long 37530356, long 37460292, long 28385284, long 28385308)
line 459 + 31 bytes
Ffuncall(int 5, long * 0x0082cfac) line 3488 + 168 bytes
Fapply(int 2, long * 0x0082d09c) line 3764 + 13 bytes
Ffuncall(int 3, long * 0x0082d098) line 3509 + 14 bytes
execute_optimized_program(const unsigned char * 0x023b78d0, int 4, long * 0x02033110) line
744 + 16 bytes
funcall_compiled_function(long 33818596, int 5, long * 0x0082d388) line 516 + 53 bytes
Ffuncall(int 6, long * 0x0082d384) line 3523 + 17 bytes
call5(long 33846956, long 28580468, long 37530356, long 37460292, long 28385284, long
28385308) line 4215 + 11 bytes
Fmswindows_insert_directory(long 37530356, long 37460292, long 28385284, long 28385308)
line 459 + 31 bytes
Ffuncall(int 5, long * 0x0082d7ac) line 3488 + 168 bytes
execute_optimized_program(const unsigned char * 0x01e5ea10, int 14, long * 0x01cb0c10)
line 744 + 16 bytes
funcall_compiled_function(long 30071684, int 4, long * 0x0082dab4) line 516 + 53 bytes
Ffuncall(int 5, long * 0x0082dab0) line 3523 + 17 bytes
Fapply(int 2, long * 0x0082dba0) line 3764 + 13 bytes
Ffuncall(int 3, long * 0x0082db9c) line 3509 + 14 bytes
execute_optimized_program(const unsigned char * 0x02327d10, int 5, long * 0x01f02190) line
744 + 16 bytes
funcall_compiled_function(long 36804160, int 5, long * 0x0082de84) line 516 + 53 bytes
Ffuncall(int 6, long * 0x0082de80) line 3523 + 17 bytes
execute_optimized_program(const unsigned char * 0x01e5ea10, int 14, long * 0x01cb0c10)
line 744 + 16 bytes
funcall_compiled_function(long 30071684, int 4, long * 0x0082e188) line 516 + 53 bytes
Ffuncall(int 5, long * 0x0082e184) line 3523 + 17 bytes
Fapply(int 2, long * 0x0082e274) line 3764 + 13 bytes
Ffuncall(int 3, long * 0x0082e270) line 3509 + 14 bytes
execute_optimized_program(const unsigned char * 0x023b78d0, int 4, long * 0x02033110) line
744 + 16 bytes
funcall_compiled_function(long 33818596, int 5, long * 0x0082e554) line 516 + 53 bytes
Ffuncall(int 6, long * 0x0082e550) line 3523 + 17 bytes
execute_optimized_program(const unsigned char * 0x01e5ea10, int 14, long * 0x01cb0c10)
line 744 + 16 bytes
funcall_compiled_function(long 30071684, int 4, long * 0x0082e85c) line 516 + 53 bytes
Ffuncall(int 5, long * 0x0082e858) line 3523 + 17 bytes
execute_optimized_program(const unsigned char * 0x023b7390, int 5, long * 0x01e96990) line
744 + 16 bytes
funcall_compiled_function(long 33606840, int 4, long * 0x0082eb40) line 516 + 53 bytes
Ffuncall(int 5, long * 0x0082eb3c) line 3523 + 17 bytes
execute_optimized_program(const unsigned char * 0x023efd90, int 6, long * 0x01e96a10) line
744 + 16 bytes
funcall_compiled_function(long 33606784, int 2, long * 0x0082ee28) line 516 + 53 bytes
Ffuncall(int 3, long * 0x0082ee24) line 3523 + 17 bytes
execute_optimized_program(const unsigned char * 0x023efc90, int 4, long * 0x01e96c90) line
744 + 16 bytes
funcall_compiled_function(long 33606756, int 3, long * 0x0082f108) line 516 + 53 bytes
Ffuncall(int 4, long * 0x0082f104) line 3523 + 17 bytes
execute_optimized_program(const unsigned char * 0x01e00f10, int 5, long * 0x01fde310) line
744 + 16 bytes
funcall_compiled_function(long 33606644, int 2, long * 0x0082f3ec) line 516 + 53 bytes
Ffuncall(int 3, long * 0x0082f3e8) line 3523 + 17 bytes
execute_optimized_program(const unsigned char * 0x0239e590, int 3, long * 0x02000150) line
744 + 16 bytes
funcall_compiled_function(long 33606420, int 2, long * 0x0082f6cc) line 516 + 53 bytes
Ffuncall(int 3, long * 0x0082f6c8) line 3523 + 17 bytes
execute_optimized_program(const unsigned char * 0x023b0190, int 4, long * 0x01fe4a70) line
744 + 16 bytes
funcall_compiled_function(long 33606336, int 2, long * 0x0082f9a4) line 516 + 53 bytes
Ffuncall(int 3, long * 0x0082f9a0) line 3523 + 17 bytes
Fapply(int 2, long * 0x0082fa14) line 3764 + 13 bytes
apply1(long 33606336, long 37238812) line 4117 + 11 bytes
Fcall_interactively(long 30085340, long 28385284, long 28385284) line 465 + 13 bytes
Fcommand_execute(long 30085340, long 28385284, long 28385284) line 2929 + 17 bytes
execute_command_event(command_builder * 0x01e48200, long 31615200) line 3903 + 25 bytes
Fdispatch_event(long 31615200) line 4195 + 70 bytes
Fcommand_loop_1() line 583 + 9 bytes
command_loop_1(long 28385284) line 495
condition_case_1(long 28385380, long (long)* 0x01069399 command_loop_1(long), long
28385284, long (long, long)* 0x01068db0 cmd_error(long, long), long 28385284) line 1692 +
7 bytes
command_loop_3() line 256 + 35 bytes
command_loop_2(long 28385284) line 269
internal_catch(long 28465804, long (long)* 0x01068f00 command_loop_2(long), long 28385284,
int * volatile 0x00000000) line 1317 + 7 bytes
initial_command_loop(long 28385284) line 305 + 25 bytes
STACK_TRACE_EYE_CATCHER(int 1, char * * 0x01b08fd8, char * * 0x01d9bd00, int 0) line 2481
main(int 1, char * * 0x01b08fd8, char * * 0x01d9bd00) line 2915
XEMACS! mainCRTStartup + 180 bytes
_start() line 171
Auto variables in mswindows_format_file:
add_newline 1
- puta 0x0082c0e4
- data_ 0x0082be54 "drwxrwxrwx 2 AichnerAd 0 0 Mar 20 2000
$OEM$"
100 'd'
max_size_allocated_ 72
bytelen_ 61
charlen_ 61
mallocp_ 0
- extdata_ 0x00000000 ""
CXX0030: Error: expression cannot be evaluated
extlen_ 0
Matej> ----- Original Message -----
Matej> From: "Ben Wing" <ben(a)666.com>
Matej> To: "XEmacs MULE" <xemacs-mule(a)xemacs.org>; "XEmacs NT
List" <xemacs-nt(a)xemacs.org>; "XEmacs beta list"
<xemacs-beta(a)xemacs.org>
Matej> Sent: Tuesday, August 21, 2001 10:21 AM
Matej> Subject: Please check out my new, Mule-on-Windows, full Unicode support
XEmacs!
Matej> Almost any operations regarding network drive will GPF XEmacs instantly.
Matej> Example of a GPF producing command (XEmacs was started with --vanilla
option):
Matej> (dired "\\\\tau\\e\$\\")
Matej> Unfortunately the debug window is closed so fast, that I am unable to
capture the output. All I was able to do in that time was to snapshot the picture of the
window. See attachment.
Matej> BTW: I would really appreciate if someone would help me configure the XEmacs
21.5 for CP1250 and CP852 support. Otherwise I can only do minimal testing.
Matej> *** Installation Information
Matej> OS version:
Matej> Microsoft Windows 2000 [Version 5.00.2195]
Matej> OS: Windows_NT
Matej> XEmacs 21.5-b2 \"artichoke\" configured for `i586-pc-win32'.
Matej> Building XEmacs in \"W:\\xemacs-21.5\\nt\".
Matej> Using compiler \"cl -nologo -W3 -O2 -G5 -ML\".
Matej> Installing XEmacs in
\"e:\\razno\\XEmacs\\XEmacs-21.5-b2-mule\".
Matej> Package path is
\"~\\.xemacs;;e:\\razno\\xemacs\\site-packages;e:\\razno\\xemacs\\mule-packages;e:\\razno\\xemacs\\xemacs-packages\".
Matej> Compiling in support for Microsoft Windows native GUI.
Matej> Compiling in MULE.
Matej> Compiling in support for XPM images.
Matej> Compiling in support for GIF images.
Matej> Compiling in support for PNG images.
Matej> Compiling in support for TIFF images.
Matej> Compiling in support for JPEG images.
Matej> Compiling in support for X-Face message headers.
Matej> Compiling in support for toolbars.
Matej> Compiling in support for dialogs.
Matej> Compiling in support for widgets.
Matej> Compiling in support for native sounds.
Matej> Compiling in fast dired implementation.
--
Adrian Aichner
mailto:adrian＠xemacs.org
http://www.xemacs.org/
4:40 p.m.
New subject: SUGGESTION: Mule-on-Windows, full Unicode support XEmacs
I'm looking for testers. There is a complete and fast
implementation
in C of Unicode conversion, translations for almost all of the
standardly-defined charsets that load up automatically and
...
It's so far hooked into one place: the Windows IME. Currently I
can
select the Japanese IME from the thing on my tray pad in the lower
...
Please, keep in mind that I am no Windows and/or XEmacs expert so it is possible that I am
suggesting something that is not possible or that duplicates existing functionality.
XEmacs is now hooked into Windows-only API for Unicode. Could this be extended to include
and use the WinAPI built-in functions for translating Unicode to ANSI and Unicode to OEM
(or Unicode <-> ANSI <-> OEM).
Is it possible to create support for a "generic" coding systems that would use
this Windows functions?
mswindows-oem-dos, mswindows-oem-mac, mswindows-oem-unix
mswindows-ansi-dos, mswindows-ansi-mac, mswindows-ansi-unix
Perhaps I assume wrong, but wouldn't such coding systems read and write transparently
Unicode buffers into whatever codepage the user's Windows installation defines as ANSI
or OEM codepage ? For me, since I use Eastern Europe / Slovenian locale, this would be
CP1250 and CP852. For a user with different locale it would be different.
Regards,
Matej Mihelic
5:06 p.m.
New subject: SUGGESTION: Mule-on-Windows, full Unicode support XEmacs
Would having POSIX wide-character and/or full locale support do the trick?
Not that I have it in my pocket, I'm afraid.
At 8/22/01 11:40 AM (Wednesday), Matej Mihelic wrote:
> I'm looking for testers. There is a complete and fast
implementation
> in C of Unicode conversion, translations for almost all of the
> standardly-defined charsets that load up automatically and
...
> It's so far hooked into one place: the Windows IME. Currently I can
> select the Japanese IME from the thing on my tray pad in the lower
...
Please, keep in mind that I am no Windows and/or XEmacs expert so it is
possible that I am suggesting something that is not possible or that
duplicates existing functionality.
XEmacs is now hooked into Windows-only API for Unicode. Could this be
extended to include and use the WinAPI built-in functions for translating
Unicode to ANSI and Unicode to OEM (or Unicode <-> ANSI <-> OEM).
Is it possible to create support for a "generic" coding systems that would
use this Windows functions?
mswindows-oem-dos, mswindows-oem-mac, mswindows-oem-unix
mswindows-ansi-dos, mswindows-ansi-mac, mswindows-ansi-unix
Perhaps I assume wrong, but wouldn't such coding systems read and write
transparently Unicode buffers into whatever codepage the user's Windows
installation defines as ANSI or OEM codepage ? For me, since I use
Eastern Europe / Slovenian locale, this would be CP1250 and CP852. For a
user with different locale it would be different.
Regards,
Matej Mihelic
David A. Cobb, Software Engineer, Public Access Advocate, All around nice guy.
Get my PGP key at
:<http://pgpkeys.mit.edu:11371/pks/lookup?op=get&search=superbiskit>
Fingerprint=0x{6E3E_DB8C_2E8C_4248_62B2_FE29_08EE_CF0A_3629_E954}
:<http://wwwkeys.pgp.net:11371/pks/lookup?op=get&search=superbiskit&fingerprint=on>
"By God's Grace I am a Christian man, by my actions a great sinner."
--The Way of a Pilgrim, R. M. French [tr.]
Potentially Viral Software is any software for which you are not allowed
to examine the source. Do not buy or use Potentially Viral Software!
<---.----!----.----!----.----!----.----!----.----!----.----!----.---->
1:49 a.m.
New subject: SUGGESTION: Mule-on-Windows, full Unicode support XEmacs
i already do all of this and more. [well, i don't do OEM support, but it's not
needed.]
in my latest workspaces, you should be able to use Eastern European by default
with no setup needed -- just switch to the appropriate keyboard layout. [same
for Cyrillic, modulo the "Russian C-x problem"]
the coding system `mswindows-multibyte' converts from Windows ANSI in the the
system-default code page. [hmm, i should add a parameter to specify the code
page]
Matej Mihelic wrote:
> I'm looking for testers. There is a complete and fast implementation
> in C of Unicode conversion, translations for almost all of the
> standardly-defined charsets that load up automatically and
...
> It's so far hooked into one place: the Windows IME. Currently I can
> select the Japanese IME from the thing on my tray pad in the lower
...
Please, keep in mind that I am no Windows and/or XEmacs expert so it is possible that I
am suggesting something that is not possible or that duplicates existing functionality.
XEmacs is now hooked into Windows-only API for Unicode. Could this be extended to include
and use the WinAPI built-in functions for translating Unicode to ANSI and Unicode to OEM
(or Unicode <-> ANSI <-> OEM).
Is it possible to create support for a "generic" coding systems that would use
this Windows functions?
mswindows-oem-dos, mswindows-oem-mac, mswindows-oem-unix
mswindows-ansi-dos, mswindows-ansi-mac, mswindows-ansi-unix
Perhaps I assume wrong, but wouldn't such coding systems read and write transparently
Unicode buffers into whatever codepage the user's Windows installation defines as ANSI
or OEM codepage ? For me, since I use Eastern Europe / Slovenian locale, this would be
CP1250 and CP852. For a user with different locale it would be different.
Regards,
Matej Mihelic
10:41 a.m.
New subject: SUGGESTION: Mule-on-Windows, full Unicode support XEmacs
----- 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?
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.
- 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.
- EOL type detection doesn't detect DOS line encoding
automatically/correctly.
- 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:\)
- 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.
- 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.
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.
9:31 a.m.
New subject: 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
10:46 a.m.
New subject: 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.
8481
days inactive
8494
days old
11 comments
6 participants
participants (6)
-
Adrian Aichner -
Adrian Aichner -
Ben Wing -
Daniel Pittman -
David A. Cobb -
Matej Mihelic