From xemacs-m  Thu Aug 21 16:51:40 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 QAA21237
	for <xemacs-beta@xemacs.org>; Thu, 21 Aug 1997 16:51:39 -0500 (CDT)
Received: from Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id OAA01425; Thu, 21 Aug 1997 14:51:11 -0700
Received: from kindra.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
	id OAA03719; Thu, 21 Aug 1997 14:51:07 -0700
Received: from xemacs.eng.sun.com by kindra.eng.sun.com (SMI-8.6/SMI-SVR4)
	id OAA12328; Thu, 21 Aug 1997 14:51:06 -0700
Received: by xemacs.eng.sun.com (SMI-8.6/SMI-SVR4)
	id OAA11279; Thu, 21 Aug 1997 14:51:06 -0700
Date: Thu, 21 Aug 1997 14:51:06 -0700
Message-Id: <199708212151.OAA11279@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: Jan Vroonhof <vroonhof@math.ethz.ch>
Cc: xemacs-beta@xemacs.org, Jamie Zawinski <jwz@netscape.com>
Subject: Re: Can we please have this in XEmacs 19.16
In-Reply-To: <byen7phvyz.fsf@midget.math.ethz.ch>
References: <byhgcmqoar.fsf@midget.math.ethz.ch>
	<m2oh6u9e7m.fsf@altair.xemacs.org>
	<byen7phvyz.fsf@midget.math.ethz.ch>
X-Mailer: VM 6.33 under 20.3 "Vienna" XEmacs  Lucid (beta14)
Reply-To: Martin Buchholz <mrb@Eng.Sun.COM>

>>>>> "Jan" == Jan Vroonhof <vroonhof@math.ethz.ch> writes:

x-compose.el is not perfect yet.  To really do it right requires some
more thought.  I have a bunch of changes to x-compose.el to be put
into the next 20.3 beta.

I vote AGAINST making x-compose.el the standard behavior in 19.16:
- key composition capability may (should?) already be provided by Xlib.
- x-compose.el implementation is not yet stable.
- the issues are not yet completely understood.

From x-compose.el (jwz?):

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

Jan> SL Baur <steve@xemacs.org> writes:
>> I agree about updating x-compose.el, however, this patch is rejected.
>> If x-compose.elc is to be dumped with XEmacs, it should be done
>> correctly.  In v19 that means it must be referenced out of loadup.el
>> and src/Makefile.in.in must refer to it so its DOC strings can be
>> snarfed for the DOC file.

Jan> I am not proposing x-compose.el to be dumped. I specially put it in
Jan> the same hook as x-initialize-keyboard because of the comment.

Jan>     ;; This runs after the first frame has been created (we can't
Jan>     ;; talk to the X server before that) but before the
Jan>     ;; site-start-file or .emacs file, so sites and users have a
Jan>     ;; chance to override it.

Jan> and

Jan>     ;; We can't load this until after the initial X device is created
Jan>     ;; because the icon initialization needs to access the display to get
Jan>     ;; any toolbar-related color resources.
 
Jan> The problem is that x-composes use x-keysym-on-keyboard-p and I am
Jan> not sure whether that also talks to the X server or needs the X device
Jan> inited.

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.

The XEmacs key remapping design is not yet completely satisfactory.
Additional thought and rework would be useful.

Jan> Note that x-compose uses NO functions for its normal behaviour. It
Jan> just juggles a few keymaps when it is loaded.

Jan> Jan

Jan> Note x-win.el also does (require 'x-iso8859-1)


