From xemacs-m  Mon Aug 25 04:40:53 1997
Received: from frege.math.ethz.ch (root@frege-d-math-north-g-west.math.ethz.ch [129.132.145.3])
	by xemacs.org (8.8.5/8.8.5) with SMTP id EAA11741
	for <xemacs-beta@xemacs.org>; Mon, 25 Aug 1997 04:40:45 -0500 (CDT)
Received: from midget (vroonhof@midget [129.132.145.4]) by frege.math.ethz.ch (8.6.12/Main-STAT-mailer) with ESMTP id LAA13989; Mon, 25 Aug 1997 11:40:21 +0200
Received: (vroonhof@localhost) by midget (SMI-8.6/D-MATH-client) id LAA02667; Mon, 25 Aug 1997 11:40:20 +0200
To: Jamie Zawinski <jwz@netscape.com>
Cc: Martin Buchholz <mrb@Eng.Sun.COM>, xemacs-beta@xemacs.org
Subject: Re: Sorry I lost your mail..
References: <byu3gio17a.fsf@midget.math.ethz.ch> <33FF859C.58B699F5@netscape.com>
Mime-Version: 1.0 (generated by tm-edit 7.106)
Content-Type: text/plain; charset=US-ASCII
From: Jan Vroonhof <vroonhof@math.ethz.ch>
Date: 25 Aug 1997 11:40:20 +0200
In-Reply-To: Jamie Zawinski's message of Sat, 23 Aug 1997 17:51:40 -0700
Message-ID: <byoh6msirf.fsf@midget.math.ethz.ch>
Lines: 76
X-Mailer: Gnus v5.4.55/XEmacs 19.15


This mail contains my belated mutterings with regards to x-compose.el.
Due to to the way I got these messages the quotes won't be proberply
attributed.

I hope to make the case below why x-compose.el should be loaded upon
x-init. At least on non mule Emacsen like 19.16 and 20.x/latin1. 

A quick summary of the argument:
 -  x-compose just adds to some some keymaps. It doesn't take that
    much space and it does not break anything if your X doesn't
    generate  a Multi_Key or Dead_anyhting keysym.
 - loading it can be inhibited
 - It has its deficiencies but on none mule Emacsen there isn't any
   alternative
 - autoloading doesn't work and is probably silly anyway because there
   so many keys involved.

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

However on quite a number (this is THE faq in comp.emacs.xemacs) of
system it doesn't. Note that on some installations XEmacs is the
_only_ application where you cannot type a tilde because it gets
dead_tilde, but where standard Emacs and other X applications do work.

> > - x-compose.el implementation is not yet stable.

x-compose.el has been upgraded to use function-key-map and I have
added a few keysyms. If anything it was too stable before.  

> 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.

So it doesn't hurt.

> If XFree86 does not work this way, it's likely a bug, since the X
> documentation implies this is the way it should work.  It should have
> also worked in Solaris 2.5 (X11R5-based), but did not, due to a bug.

Which means there must be a work-around. Solaris 2.5.x will be around
for some time to come.... So will the various configuration of XFree86
and AIX.

>> >> The XEmacs key remapping design is not yet completely satisfactory.
> 
> jwz> Why?
> 
> There are 3 key-remapping mechanisms:

Note that biggest problem with the current remapping and x-compose.el
is that it is highly nontrivial to also handle modifiers correctly.
Although with x-compose.el <dead_tilde SPC> becomes '~' <control
dead_tilde SPC> does NOT become 'C-~' etc.  (Does xlib based compose
processing handle this correctly?) 

> Right. x-compose.el should at least be wrapped within 
> (x-keysym-on-keyboard-p "Multi_key")
> I'll implement this change for the next beta.

Remember to put the wrapper only around the multi_key part!
X-compose.el also supports dead keys!

> OK. The right way is to autoload everything in x-compose.el whenever a 
> Multi_key event arrives.

That would be if Multi_Key support were the only thing it did (or if
dead keys had consistent namings). However currently x-compose.el
supports about 60 diffferent dead_key keysims.

Do 61 autoload cookies really occuppy much less space than the current
keymaps?

Jan
 

