From xemacs-m  Thu Aug 21 17:08:53 1997
Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47])
	by xemacs.org (8.8.5/8.8.5) with ESMTP id RAA21871
	for <xemacs-beta@xemacs.org>; Thu, 21 Aug 1997 17:08:53 -0500 (CDT)
Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54])
	by netscape.com (8.8.5/8.8.5) with ESMTP id PAA19391
	for <xemacs-beta@xemacs.org>; Thu, 21 Aug 1997 15:08:24 -0700 (PDT)
Received: from gimp ([205.217.227.11]) by dredd.mcom.com
          (Netscape Messaging Server 3.0)  with SMTP id AAA10289;
          Thu, 21 Aug 1997 15:08:21 -0700
Sender: jwz@netscape.com (Jamie Zawinski)
Message-ID: <33FCBC19.DCCCF8C3@netscape.com>
Date: Thu, 21 Aug 1997 15:07:21 -0700
From: Jamie Zawinski <jwz@netscape.com>
Organization: Netscape Communications Corporation, Mozilla Division
X-Mailer: Mozilla 3.02 (X11; U; IRIX 6.2 IP22)
MIME-Version: 1.0
To: Martin Buchholz <mrb@Eng.Sun.COM>
CC: Jan Vroonhof <vroonhof@math.ethz.ch>, xemacs-beta@xemacs.org
Subject: Re: Can we please have this in XEmacs 19.16
References: <byhgcmqoar.fsf@midget.math.ethz.ch>
		<m2oh6u9e7m.fsf@altair.xemacs.org>
		<byen7phvyz.fsf@midget.math.ethz.ch> <199708212151.OAA11279@xemacs.eng.sun.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Martin Buchholz wrote:
> 
> I vote AGAINST making x-compose.el the standard behavior in 19.16:
> - key composition capability may (should?) already be provided by Xlib.

"Should" would be a hard sell, since the X Consortium Party Line is
that the compose key is a Bad Thing, and one should use input methods
instead.  

That's why the XFree86 Xlibs don't do it.

> - x-compose.el implementation is not yet stable.
> - the issues are not yet completely understood.

What's the problem again?

> ;; If you are running a version of X which already does compose processing,
> ;; then you don't need this file.  But the MIT R4 and R5 distributions don't
> ;; do compose processing, so you may want to fake it by using this code.
> 
> Jamie, you're the x keysym expert.  Would you like to cast a vote?

If Xlib does compose processing, then loading x-compose.el will have
no effect -- because if Xlib does compose processing, Emacs will never
see the Multi_key keysym at all.

However, one reason someone might actually *prefer* x-compose.el to what
Xlib does is that x-compose.el lets you type C-h in the middle of a
composition sequence to list the possible completions.  It's a nifty
feature that Xlib can't provide.

> Right.  The action x-compose.el takes is device-dependent.  To be
> truly correct, we would have different function-key-maps on different
> consoles, but it's not clear this is worth the extra complexity.

Yeah.  I don't know; it's a mess.

> The XEmacs key remapping design is not yet completely satisfactory.

Why?

> Jan> Note that x-compose uses NO functions for its normal behaviour. 

Would be nice if keymaps could be autoloaded (maybe they can now, I
don't know.)

If it can be autoloaded, then I see no argument against doing that.
(Assuming it doesn't have bugs that I don't know about.)

If it can't be autoloaded, then the argument against pre-loading it
would be bloat.

Another alternative to autoloading would be to have it be loaded at
startup only if the keyboard has a Multi_key keysym on it somewhere;
most people don't.

	== Jamie

