9:10 a.m.
sorry i have been out of the loop lately. my dsl has been down for a week [and
is still down!], so my connectivity is quite reduced. it's also been the first
week of school. i have recently read the messages and will try to fix the
problems mentioned. in the meantime i've done a lot more work; in particular,
the unicode encapsulation is fully present. what this means is:
[1] whenever running on nt, xemacs automatically uses the unicode versions of
the Windows API's, which are faster and more importantly allow text in arbitrary
languages [even mixed] to be passed back and forth.
[2] on 95, we use the built-in WideCharToMultiByte API to convert to the
multi-byte API and automatically use the ANSI versions of the Windows API's.
thus, we need no translation tables for particular windows codepages.
[3] we correctly support both input and display of IME [Japanese, Chinese, etc.]
and non-IME [Russian, Greek, Polish, Hebrew, etc.] languages, in both 95 and
NT. the only missing combination currently is IME input in 95, which is easy to
fix and is high on my list.
the above mean that we now can handle most languages without [too much] problem.
There is still the dreaded "Russian C-x" problem, which i'm in the middle
of
fixing [C-x when in the Russian layout doesn't do what you think it should do
because the x key produces a Cyrillic character].
i've enabled file-coding by default in all circumstances; under unix non-mule
non-cygwin everything defaults to binary, so you get exactly what you'd get
without file-coding. you can change this, though, with a configure flag,
--with-default-encoding-detection or something, which puts back the automatic
file encoding detection that's normally present. [#### this may not work
perfectly quite yet.]
we still don't support pdump, Cygwin, or non-mule, [and perhaps unix] but i'm
working on those, too.
i'll have more time over the weekend and i'll answer specific emails then.
all of the above is checked in to branch `ben-mule-21-5'. I am updating the
file README.ben-mule-21-5 at the end of each day I do some work, and I've
recently created TODO.ben-mule-21-5, containing a prioritized list of what i'm
working on.
as always, i'm always looking for testers; bear in mind the above restrictions.
ben
2 p.m.
I build it this morning, debug version, under win2k.
I had to patch it there to turn debug on :
diff -u file-coding.c~ file-coding.c
--- file-coding.c~ Fri Aug 31 09:51:13 2001
+++ file-coding.c Fri Aug 31 14:01:44 2001
＠＠ -1900,9 +1900,9 ＠＠
())
{
#if defined (WIN32_NATIVE) || defined (CYGWIN) || defined (MULE) || defined
(HAVE_DEFAULT_ENCODING_DETECTION)
- return 1;
+ return Qt;
#else
- return 0;
+ return Qnil;
#endif
}
Dired resulted in a crash. So far 2 reasons:
1/
dired-msw.c, line 416:
eicat_c (puta, buf);
eicat_raw (puta, file->cFileName, qxestrlen (file->cFileName));
if (add_newline)
eicat_c (puta, "\n");
return eimake_string (puta);
}
eicat_c() will test that all the chars in the string are ascii ones
and assert if c < 0x20 probably better to lower the limit.
2/
Lisp backtrace follows:
mswindows-insert-directory("d:\\Source\\Gnu\\xemacs-ben\\tests\\mule\\"
"-al"
nil t)
# bind (handler full-directory-p wildcard switches file)
insert-directory("d:\\Source\\Gnu\\xemacs-ben\\tests\\mule\\" "-al"
nil t)
apply(insert-directory ("d:\\Source\\Gnu\\xemacs-ben\\tests\\mule\\"
"-al" nil
t))
# bind (inhibit-file-name-handlers inhibit-file-name-operation args
op)
dired-handler-fn(insert-directory
"d:\\Source\\Gnu\\xemacs-ben\\tests\\mule\\"
"-al" nil t)
...
The crash occured there :
dired-msw.c, line 588
for (i = 0; i < Dynarr_length (files); ++i)
{
Win32_file *file = Dynarr_atp (files, i);
=> xfree (file->cFileName);
}
Dynarr_free (files);
UNGCPRO;
return (result);
}
with these values :
+ file 0x00000004
- files 0x01b41274
+ base 0x00000004
elsize 0x00000000
cur 0x01b3ebe4
largest 0x018702f8
max 0x018c8b48
i 0x00000000
3/
I can send you the BoundsChecker compliance report if needed. I have
build xemacs-mule under BoundChecker, quite nice to catch problems.
Unfortunately, I have not enough time to dwelve inside you development
code.
4/ I have run the automated tests: all tests passed (except c-tests,
2/4 only) up to Mule tests which failed there :
Testing d:\Source\Gnu\xemacs-ben\tests\automated\mule-tests.el...
Unexpected error (file-error "Opening output file" "No such file or
directory" "
c:\\popineau\\LOCALS~1\\Temp\\~~~~kiAsDw") while executing interpreted code.
Test suite execution aborted.
Unexpected error (file-error "Opening output file" "No such file or
directory" "
c:\\popineau\\LOCALS~1\\Temp\\~~~~kiAxKm") while executing byte-compiled code.
Test suite execution aborted.
mule-tests.el: 206 of 206 (100%) tests successful.
Test suite execution failed unexpectedly.
...
Testing d:\Source\Gnu\xemacs-ben\tests\automated\symbol-tests.el...
Unexpected error (void-variable pathname-coding-system) while executing interpre
ted code.
Test suite execution aborted.
Unexpected error (void-variable pathname-coding-system) while executing byte-com
piled code.
Test suite execution aborted.
symbol-tests.el: 246 of 248 (99%) tests successful.
Test suite execution failed unexpectedly.
...
Done
5/ Is it a side effect or something else : the XEmacs icon looks a bit
less appealing than it used to.
Fabrice
1:11 p.m.
Ben, I do appreciate your efforts in bringing XEmacs to the Unicode Win World!
As for my experience of testing your work, I'd like to clarify several issues:
1. I compile XEmacs on Win32 using nt\config.inc file. When I set HAVE_MULE=1
temacs always failed. Then switched off MULE and successfully compiled
XEmacs. Conclusion -- building should go with MULE off, right?
2. (file-truename "c:\\cygwin\\usr\\") returns "c:\\usr"! It does not
occur
in neither xemacs-21.4 nor xemacs-21.5 latest.
3. I failed to type in russian. I attached two screenshots. The first one is
from your branch and the second is from xemacs-21.4.
10:33 a.m.
Nick Pakoulin wrote:
Ben, I do appreciate your efforts in bringing XEmacs to the Unicode Win World!
As for my experience of testing your work, I'd like to clarify several issues:
1. I compile XEmacs on Win32 using nt\config.inc file. When I set HAVE_MULE=1
temacs always failed. Then switched off MULE and successfully compiled
XEmacs. Conclusion -- building should go with MULE off, right?
no, exactly the opposite. MULE support is what you need to get i18n support. i
didn't realize you could get russian at all without it, and i'm not surprised
it's broken in that case.
can you tell me why it crashes? send me a backtrace or something.
2. (file-truename "c:\\cygwin\\usr\\") returns "c:\\usr"! It does
not occur
in neither xemacs-21.4 nor xemacs-21.5 latest.
yes, matej reported that too, and it's on my list to fix.
3. I failed to type in russian. I attached two screenshots. The first one is
from your branch and the second is from xemacs-21.4.
--------------------------------------------------------------------------------
Name: xemacs-wrong.gif
xemacs-wrong.gif Type: GIF Image (image/gif)
Encoding: base64
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
Name: xemacs-ru.gif
xemacs-ru.gif Type: GIF Image (image/gif)
Encoding: base64
8480
days inactive
8485
days old
3 comments
3 participants
participants (3)
-
Ben Wing -
Fabrice Popineau -
Nickolay Pakoulin