Xref: utzoo gnu.emacs.help:595 comp.windows.x:30680
Path: utzoo!utgpu!cunews!bnrgate!uunet!zaphod.mps.ohio-state.edu!julius.cs.uiuc.edu!ux1.cso.uiuc.edu!uiucdcs!carroll
From: carroll@cs.uiuc.edu (Alan M. Carroll)
Newsgroups: gnu.emacs.help,comp.windows.x
Subject: Re: Emacs under X (use of XLookupString)
Message-ID: <1990Dec16.174306.23545@ux1.cso.uiuc.edu>
Date: 16 Dec 90 17:43:06 GMT
References: <BRENNAN.90Dec14170830@bach.rtp.dg.com>
Sender: news@ux1.cso.uiuc.edu (News)
Reply-To: carroll@cs.uiuc.edu (Alan M. Carroll)
Organization: Technophiles Inc. - Engineers with Attitude
Lines: 48

In article <BRENNAN.90Dec14170830@bach.rtp.dg.com>, brennan@rtp.dg.com (Dave Brennan) writes:
> This occurs using Emacs 18.55, Epoch 3.2, and X11R4 under DG/UX.
> 
> Is anyone aware of anything Emacs (and/or Epoch) does which would affect
> the results of XLookupString?
> 
> The problem I'm seeing is that in other X applications (like xev) is the
> XLookupString is returning different information for the exact same
> keypresses under two different applications.

To quote from the Epoch manual, page 51, epoch::rebind-key

	"This function does not affect keybindings for other X clients,
	 but does affect all Epoch screens".

Getting different results from XLookupString() in different
applications is a function of the XRebindKeysym() function. Quoting
from the X manual, page 205 (R3), XRebindKeysym(),

	"It [XRebindKeysym()] does not redefine any key in the X server
	 but merely provides an easy way for long strings to be attached
	 to keys."

> 
> By default the modifer keysym (Alt_R) is on mod bit 1, but if I move it to
> mod bit 3 both applications behave correctly.  It seems like XLookupString
> should care about the modifer bit set, not the specific keysym.  Since it
> doesn't seem to matter what modifer bit the Alt_R keysym sets, it appears
> that this isn't the case.

You are correct. I consider this to be a bug in the X window system. A
look at the XRebindKeysym() function shows that the modifier argument
is _a list of KeySyms_, not a shiftmask. Therefore there is little a
client can do to get the behaviour that seems "right" if xmodmap moves
the modifer keysyms/bits around. What epoch::rebind-key does is, when
it is called, the requested shiftmask is converted a keysym list,
which is then used to rebind the key. If the modifier mapping is later
changed, this loses. If anyone has a good suggestion other than
storing every rebound key and rebinding them whenever a MappingNotify
comes through, I'd like to hear it.

(Of course, I could just put MappingNotify's onto the Epoch X event Q,
and user code could then do this.)

-- 
Alan M. Carroll                "It's psychosomatic. You need a lobotomy.
Epoch Development Team          I'll get a saw."
CS Grad / U of Ill @ Urbana    ...{ucbvax,pur-ee,convex}!cs.uiuc.edu!carroll