From xemacs-m  Thu Jun  5 14:46:35 1997
Received: from mail.cis.ohio-state.edu (mail.cis.ohio-state.edu [164.107.8.55])
	by xemacs.org (8.8.5/8.8.5) with SMTP id OAA17286
	for <xemacs-beta@xemacs.org>; Thu, 5 Jun 1997 14:46:34 -0500 (CDT)
Received: from calico.cis.ohio-state.edu (calico.cis.ohio-state.edu [164.107.142.11]) by mail.cis.ohio-state.edu (8.6.7/8.6.4) with ESMTP id PAA01148; Thu, 5 Jun 1997 15:46:17 -0400
Received: (ware@localhost) by calico.cis.ohio-state.edu (8.8.0/8.6.4) id PAA20434; Thu, 5 Jun 1997 15:46:17 -0400 (EDT)
To: jhod@po.iijnet.or.jp (P. E. Jareth Hein)
Cc: xemacs-beta@xemacs.org
Subject: Re: Emacs, XEmacs and MULE
References: <vwmenai5yo2.fsf@calico.cis.ohio-state.edu> <u4vi3tvipr.fsf@pentagana.sonic.jp>
From: Pete Ware <ware@cis.ohio-state.edu>
Date: 05 Jun 1997 15:46:15 -0400
In-Reply-To: jhod@po.iijnet.or.jp's message of 05 Jun 1997 12:20:32 +0900
Message-ID: <vwmoh9kzvco.fsf@calico.cis.ohio-state.edu>
Lines: 33
X-Mailer: Gnus v5.4.55/XEmacs 20.3(beta3)

jhod@po.iijnet.or.jp (P. E. Jareth Hein) writes:

> Pete Ware <ware@cis.ohio-state.edu> writes:
> 
>...
> > ...
> > After listening to Naggum's complaints, I'm looking for a little bit
> > of reassurance.  Are all of his complaints due 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. ...
> 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.

Ok, I think I'm starting to understand things better and it sounds
like XEmacs/MULE are doing things right.

In light of recent messages from Eric, it sounds as though he is
annoyed that the current coding systems MULE writes to disk are
non-standard.  But there is nothing (I hope) to stop MULE from
actually truly supporting _any_ representation and converting it to
something internal (aka emacs-mule).

The other thing Eric finds annoying is that this internal
representation is visible at the lisp level instead of being properly
abstracted away -- but this is only true in FSF Emacs and not XEmacs.

--pete

