From xemacs-m  Wed Jun  4 22:36:45 1997
Received: from pentagana.sonic.jp (jhod@tc-5-017.tokyo.gol.com [203.216.8.17])
	by xemacs.org (8.8.5/8.8.5) with ESMTP id WAA19901
	for <xemacs-beta@xemacs.org>; Wed, 4 Jun 1997 22:36:42 -0500 (CDT)
Received: (from jhod@localhost) by pentagana.sonic.jp (8.7.1+2.6Wbeta4/3.4W3) id MAA00429; Thu, 5 Jun 1997 12:20:34 +0900
To: xemacs-beta@xemacs.org
Subject: Re: Emacs, XEmacs and MULE
References: <vwmenai5yo2.fsf@calico.cis.ohio-state.edu>
From: jhod@po.iijnet.or.jp (P. E. Jareth Hein)
In-Reply-To: Pete Ware's message of 04 Jun 1997 08:40:29 -0400
Mime-Version: 1.0 (generated by tm-edit 7.106)
Content-Type: text/plain; charset=US-ASCII
Date: 05 Jun 1997 12:20:32 +0900
Message-ID: <u4vi3tvipr.fsf@pentagana.sonic.jp>
Lines: 36
X-Mailer: Gnus v5.4.52/XEmacs 20.2

Pete Ware <ware@cis.ohio-state.edu> writes:

> Not having any real use for MULE, I've been quietly accepting it's
> adoption into XEmacs.  At a high level, it seems like the right
> solution to be able to handle multiple languages at the same time.
> Since I can compile XEmacs without it, I'm willing to wait until
> either the software or the hardware gets fast enough it isn't
> noticable.

As to the speed comparison, with the possible exceptions of things
that do a LOT of I/O, I really am rather pleased with XEmacs/MULE's
speed (one of the machines I use at the office is a Pentium-75 running 
Linux-2.0.30, 24MB RAM and little noticable slowness).

> After listening to Naggum's complaints, I'm looking for a little bit
> of reassurance.  Are all of his complaints do to Emacs not using a
> layer of abstraction?  Is MULE introducing a file encoding that no one 
> else in the world uses (this is the question that really worries me)?

Um, not exactly.  XEmacs/MULE and FSF-emacs MULE use a rather
interesting _internal_ coding that is unique unto us, but this never
hits the disk.  When reading a file, MULE attempts to determine the
encoding and then codes it into the internal representation.  Upon
writing the buffer gets converted into whatever that buffer's encoding
tells it to be (can be set with set-file-coding-system, a buffer local
variable).  Of course, if there are character runs in the buffer that
can't be encoded in the particular coding-system, those runs do get
thrashed (silently, to boot).  This is why the read/write parts of
MULE are so much slower.  What I believe Mr. Naggum's complaints are
most pertinent to are related to the failure of FSF-emacs to properly
abstract the buffer contents, making elisp code much more fragile and
cumbersome in the process.
 
--
Jareth

