|--==> "ML" == Mats Lidell <matsl(a)contactor.se&gt; writes: ML> Hi, ML> I've been thinking of trying out 'with-mule' in parallel with the ML> standard beta non-mule build I'm using. Is that possible? Would I need ML> two different sets of the elisp packages (with and without) or is it ML> possible to use a non-mule XEmacs with elisp packages build with a ML> MULE XEmacs? You shouldn't run into problems. Mule packages get installed into their own tree (/usr/local/lib/xemacs/mule-packages/) and a non-Mule XEmacs doesn't put that directory into the load-path. I have 6 different XEmacsen in parallel here (a Mule & non-Mule of each of 21.[145]) all using the same set of packages. The way I do it is to: - Install my everyday "production" XEmacs in the normal default place (/usr/local) and install all the packages I want in the normal default place. - For the extra XEmacsen I './configure --prefix=/other/dir'. 'make', and then 'make install'. - Finally make a symlink from the installed packages tree to $prefix/lib/xemacs ln -s /usr/local/lib/xemacs $prefix/lib/xemacs Works great. The hard part is when you have half a dozen different XEmacsen all running simultaneously, remembering what you are doing in each one. :-) Oh, and BTW, if you have ever installed an XEmacs package using the XEmacs package tools or from downloading from the FTP site, you are using packages built with a Mule XEmacs. ML> Somewhat related: (Curious) What is the rational in supporting both ML> versions. Why not just support with mule? Probably because when Mule was first implemented it was as buggy as hell and as slow as your grandmother. I don't think that's the case now, and the work that Ben is currently doing is probably a prelude to a Mule-only XEmacs. -- |---<Steve Youngs>---------------<GnuPG KeyID: 10D5C9C5>---| | XEmacs - It's not just an editor. | | It's a way of life. | |------------------------------------&lt;youngs(a)xemacs.org&gt;---|

Mats> Well I was hoping for some hard facts here like how much Mats> bigger it will get. We don't know. I can give you an upper bound: UTF-2000 XEmacs balloons from 9MB to 38MB RSS on the Alpha. But Ben's new implementation is likely to be smaller. Mats> Once in a while elisp developers seems to forget that their Mats> code should work both for mule and non-mule (if that even is Mats> feasible) and subtle bugs occur. They're supposed to be _able_ to forget. The mule/no-mule problems are usually not subtle at all: (1) people put non-unibyte code into a Lisp file, and no-mule can't read it, or (2) code signals a missing resource (Mule) under no-mule. But this is no different from the current "no-menubar XEmacs blows chunks" thread; you have to test for a feature before using it. So yes, it's a problem and annoying, but it's not "subtle"; it's usually possible to provide workarounds (move the lookup package, build with Mule) quickly. Mats> If the non-mule version is dropped I guess these problems Mats> would go away. The experience in GNU Emacs has been otherwise. They periodically have problems with *-as-unibyte issues, not to mention the recurring "\201 in Latin-1 files" bug. Mats> So I was curios about what consequences it would have to Mats> drop non mule. Merits: o One less feature to check for in "generic" code. o Lisp developers would be encouraged to be Mule conscious, and internals developers would be encouraged to provide mechanisms to Do The Right Thing without "doing Mule." o People who don't often need Mule facilities would have them available, find more uses for them, and all the good that flows from open source will be enhanced. Demerits: o The costs of Mule consciousness for Lisp developers, and the costs to internals developers of thinking up and providing APIs that DTRT without the Lisp developer doing anything special. o The subtle bugs will be more common until the first point is addressed. o Developers who have up to now been able to add features without worrying about Mule issues, and let the specialists add them later, will have a lot less room to wiggle. o Executable footprint will get larger by default. Mostly we'll lazy load (at least that's Ben's plan), but the default will be to load UTF-8 support rather than accept a couple of \202's in the buffer. o Buffer footprint will get larger for unibyte users (Latin-X characters double in size). Depending on the frequency of those characters, it could be anything from nearly 0% (British users who don't mention money) to nearly 100% (Cyrillic, Greek, Arabic, Hebrew) increase. This means a reduction in maximum buffer size, I believe (I think that byte counts as well as character counts must fit in a Lisp integer in the current implementation). And people have objected to changes on that basis in the past. o Mule operations are alleged to be slower, but it's been surprisingly hard to quantify. o By default multiscript usage will often have surprising results, for example files may get automatically translated to Unicode or ISO 2022. This kind of thing could theoretically occur simply by mixing ISO-8859 1 with 15. We'll try to be sensible about designing those features, but it's unknown territory. I know several people who complain bitterly about "surprises" that I consider natural or even "features". o Backwards compatibility with existing no-mule XEmacsen (we _still_ get occasional bug reports from satisfied 19.14 users) will suffer. That's what I know offhand, I'm sure there are others. -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Don't ask how you can "do" free software business; ask what your business can "do for" free software.

On 22 Apr 2002, Stephen J. Turnbull wrote: CC to Ben because it's relevant to him. :) The current effect of the 21.5 series with Ben's current set of code is an expansion from 48MB, after a day of running, to 130MB on startup. This is with a bunch of code, Gnus included, loaded, but even so, that's an expansion of four times larger for a startup and, in practice, about the same at runtime. The new code is /big/, especially at runtime. This is a bad thing(tm). I am happy to do what I can to improve the situation, but at the moment I have run out of ideas as to what to look at. Ben, or anyone else, if you have suggestions about where to look to track down what the expansion is, please suggest them. The internals have no fear for me.[1] Daniel Footnotes: [1] Well, something like that, anyway. I can learn 'em. ;) -- Despite all my rage I am still just a rat in a cage. Now I'm naked, nothing but an animal. -- The Smashing Pumpkins, _Bullet With Butterfly Wings_ (Mellon Collie And The Infinite Sadness)

On 22 Apr 2002, Stephen J. Turnbull wrote: Oh. Sorry, I didn't pick that up from your post. Right. Well, my offer to try and help stands. :) Daniel -- The true believer is eternally incomplete, eternally insecure. -- Eric Hoffer