breck@umvlsi.ECS.UMASS.EDU (William Breck) (07/14/89)
POTHIERS%TUVA.SAINET.MFENET@CCC.MFECC.LLNL.GOV writes: >Is there a version of GNU Emacs that runs nicely under X? Unix Review of July 89 reviewed GNU Emacs version 18.53 and reported: "GNU Emacs comes with rudimentary support for the X Window system (versions 10 and 11). It currently lacks the ablility to use the mouse for scrolling, and pop-up menus are only minimally implemented. GNU Emacs version 19 will include full support for X11." I don't know when version 19 will be released, but you can contact the Free Software Foundation, the publisher of GNU Emacs, directly or through the gnu.* newsgroups. You can ask more questions in the comp.emacs newsgroup. Bill Breck | University of Massachusetts at Amherst | "The ones who give the orders Internet: breck@umvlsi.ecs.umass.edu | are not the ones who die..." Bitnet: breck@umaecs |
brennan@rtp.dg.com (Dave Brennan) (12/15/90)
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. This happens when a modifer
key is used on an Sweedish keyboard to generate ASCII characters. I
suspect there may be some strange processing going in our server or
libraries with respect to the modifer key, but that still doesn't explain
why two different applications linked with the same libX11.a behave
differently, unless Emacs or Epoch is doing something else funny.
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.
Here's one entry from "xmodmap -pk" for a key that generates the vertical
bar when the Alt_R key is down. I was unable to find any useful
documentation on exactly what the third column entry means (or the forth if
there was one).
There are 4 KeySyms per KeyCode; KeyCodes range from 8 to 133.
KeyCode Keysym (Keysym) ...
Value Value (Name) ...
20 0x003c (less) 0x003e (greater) 0x007c (bar)
|\
Dave Brennan | \____oo_ brennan@rtp.dg.com
=========================================((__| /___> ...rti!dg-rtp!brennan
User Interfaces, Data General | // daveb@rpitsmts.bitnet
Research Triangle Park, NC |// Phone: (919) 248-6330carroll@cs.uiuc.edu (Alan M. Carroll) (12/17/90)
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