>>>>> [15 Aug 1999 11:40:56 -0400]
>>>>> Vin Shelton <acs(a)xemacs.org> writes:
Vin> I am completely ignorant when it comes to mule. If someone can
Vin> tell me what needs to be done and if xemacs-review can achieve
Vin> consensus on that, I will gladly make 21.1.7 compatible with
Vin> mule-base 1.32. In the meantime, if mule-base 1.32 really
Vin> doesn't work with 21.1.6, shouldn't we put a mule-base 1.31
Vin> package on the ftp site and include directions pointing people to
Thanks for that. I wonder it is specific to Japansese environment, but
I'm not sure. The next diff shows the problem Japansese users
encountered. It is for japanese.el in XEmacs 21.1.
--- lisp/mule/japanese.el.orig Sat Mar 27 20:56:54 1999
+++ lisp/mule/japanese.el Mon Aug 16 01:20:32 1999
＠＠ -219,7 +219,7 ＠＠
(copy-coding-system 'euc-jp 'japanese-euc)
- "Japanese" '((setup-function . setup-japanese-environment)
+ "Japanese" '((setup-function . setup-japanese-environment-internal)
(tutorial . "TUTORIAL.ja")
(charset . (japanese-jisx0208 japanese-jisx0208-1978
In mule 1.32 the function setup-japanese-environment tries to pass
"Japanese" to the function set-language-environment. The diff shows
set-language-environment tries to call setup-japansese-environment.
Thus it is endless, causing max-lisp-eval-depth overflow.
(I have little idea what will happen on other language environments,
but there may be some problems.)
The fix might be far from perfect (21.1.4 could be compiled with some
code conversion problems but 21.1.6 failed). Next I tried to apply all
the mule-related diffs between 21.1 and 21.2. There's some problems.
First, 21.2 contains some utf-8/ucs-4 related codes (it may be easy to
remove them). Second, the codes depend on subrs
(define-coding-system-alias and split-char) which are not defined in
21.1. Since I'm not a C programmer that's as far as I could