From xemacs-m  Thu Aug 21 18:07:17 1997
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by xemacs.org (8.8.5/8.8.5) with SMTP id SAA22688
	for <xemacs-beta@xemacs.org>; Thu, 21 Aug 1997 18:07:16 -0500 (CDT)
Received: from Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id QAA16923; Thu, 21 Aug 1997 16:06:16 -0700
Received: from kindra.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
	id QAA20312; Thu, 21 Aug 1997 16:06:13 -0700
Received: from xemacs.eng.sun.com by kindra.eng.sun.com (SMI-8.6/SMI-SVR4)
	id QAA17879; Thu, 21 Aug 1997 16:06:10 -0700
Received: by xemacs.eng.sun.com (SMI-8.6/SMI-SVR4)
	id QAA11296; Thu, 21 Aug 1997 16:06:10 -0700
Date: Thu, 21 Aug 1997 16:06:10 -0700
Message-Id: <199708212306.QAA11296@xemacs.eng.sun.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
From: Martin Buchholz <mrb@Eng.Sun.COM>
To: Jamie Zawinski <jwz@netscape.com>
Cc: Jan Vroonhof <vroonhof@math.ethz.ch>, xemacs-beta@xemacs.org
Subject: Re: Can we please have this in XEmacs 19.16
In-Reply-To: <33FCBC19.DCCCF8C3@netscape.com>
References: <byhgcmqoar.fsf@midget.math.ethz.ch>
	<m2oh6u9e7m.fsf@altair.xemacs.org>
	<byen7phvyz.fsf@midget.math.ethz.ch>
	<199708212151.OAA11279@xemacs.eng.sun.com>
	<33FCBC19.DCCCF8C3@netscape.com>
X-Mailer: VM 6.33 under 20.3 "Vienna" XEmacs  Lucid (beta14)
Reply-To: Martin Buchholz <mrb@Eng.Sun.COM>

>>>>> "jwz" == Jamie Zawinski <jwz@netscape.com> writes:

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

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

The compose key should be used by input methods in (at least) western locales.

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

I believe what is deprecated is not the Compose Key itself, but
compose key processing using the XComposeStatus with XLookupKeysym.
XEmacs 20/mule uses (if possible) XmbLookupString, which does not use
XComposeStatus.

You are correct that input methods are the approved thing, but in
Western locales there should be an input method built into Xlib which
gets used.  At least this is how Solaris 2.6 (released this week?)
works: if the user composes a key using Multi_key, XEmacs does not
receive any events until the composed sequence is complete,
i.e. XEmacs will NEVER receive a KeyPress event with a Multi_key
keysym.  So on Solaris 2.6 x-compose.el is entirely bloat, as its
functionality will never be accessed. 

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.

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

jwz> 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?

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

jwz> However, one reason someone might actually *prefer* x-compose.el to what
jwz> Xlib does is that x-compose.el lets you type C-h in the middle of a
jwz> composition sequence to list the possible completions.  It's a nifty
jwz> 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.

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

I just noticed that `function-key-map' claims to be a "console-local"
variable.  Hmmmmmmm.

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

jwz> Why?

There are 3 key-remapping mechanisms:

- function-key-map:    remaps key sequences, does NOT override
- key-translation-map: remaps key sequences, DOES override
- key-translate-table: remaps keysyms, DOES override

Clearly there is something missing here (3 is not a power of 2!)
We need something that remaps keysyms, and does NOT overridde.  This
is so that we can remap, say [f33] to [kp-home], but still respect a
user's own keybinding directly to [f33].

Keybindings should perhaps be filtered through x-keysym-on-keyboard-p, 
so that teach-extended-commands and the menubar will not suggest keys
that the user does not have on the keyboard.

("You idiot! You could have used the Foobar key to run that command"
 "Huh?  I don't have any such Foobar key")

How come function-key-map claims to be console-local, but
key-translation-map does not?

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

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

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

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

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

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

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.

Martin

