Mule-base 1.32 hoses 21.1.x [was: XEmacs Build Report for XEmacs-21.1.6]

[Sorry for the quoting style; upgrades in VM and SuperCite have left me hosed.] Vin> I am completely ignorant when it comes to mule. If someone can Vin> tell me what needs to be done This is not clear to me. I think I understand the point of the change made in mule-base, but I'm not sure it's the right implementation. The big problem is the current organization of Mule-related files. We have inherited a mess in which the files in the mule-base package are interdependent with the ones in the lisp/mule core. I'm going to try to work on describing the Mule API, but it's not easy, since so much of it is undocumented, and the implementors feel completely free to use undocumented counterintuitive hacks in the core code. Tetsu> Thanks for that. I wonder it is specific to Japansese Tetsu> environment, but I'm not sure. The next diff shows the problem Tetsu> Japansese users encountered. It is for japanese.el in XEmacs Tetsu> 21.1. [...] Tetsu> In mule 1.32 the function setup-japanese-environment tries to Tetsu> pass "Japanese" to the function set-language-environment. The Tetsu> diff shows set-language-environment tries to call Tetsu> setup-japansese-environment. Thus it is endless, causing Tetsu> max-lisp-eval-depth overflow. (I have little idea what will Tetsu> happen on other language environments, but there may be some Tetsu> problems.) Right. It looks like the intent here is that all environment changes should go through `set-language-environment'. I think this is correct; the behavior of `set-language-environment' should be driven via the data in `language-info-alist', and `setup-<language>-environment' should do as little as possible. Unfortunately, `setup-<language>-environment' is currently defined as an interactive command, which is evil. This usage ought to be made obsolete immediately (interactive usage should simply warn the user and exit), and removed as soon as possible. The byte-compiler should complain, too. People also use it in their .emacs. Ugh. So probably for compatibility purposes, we should (eg) (defun setup-japanese-environment () (interactive) (if (interactive-p) (error "setup-japanese-environment is obsolete; use `M-x set-language-environment RET japanese RET'") (set-language-environment "japanese"))) The name setup-japanese-environment-internal is pretty bad; this function should live in japanese.el, so a logical name is something like `japanese-environment-setup-function' (or maybe leave out the "environment", then it would correspond very well to the `setup-function' slot in `language-info-alist'). I think that we should think about making locale packages. The problem is that (for reasons I don't understand, help me, Steve?) these language-specific files get dumped. Tetsu> The fix might be far from perfect (21.1.4 could be compiled Tetsu> with some code conversion problems but 21.1.6 failed). Next I Error messages? I did not do a full rebuild, but I did remove src/xemacs and redump. That was successful (after applpying your patch). Tetsu> tried to apply all the mule-related diffs between 21.1 and Tetsu> 21.2. There's some problems. First, 21.2 contains some Tetsu> utf-8/ucs-4 related codes (it may be easy to remove Tetsu> them). Second, the codes depend on subrs Tetsu> (define-coding-system-alias and split-char) which are not Tetsu> defined in 21.1. Since I'm not a C programmer that's as far as Tetsu> I could understand. Don't do this. Much of the mule diffs are very experimental and definitely do not belong in a stable version, which 21.1.x is supposed to be. -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 __________________________________________________________________________ __________________________________________________________________________ What are those two straight lines for? "Free software rules."