Oreilly's Xt Intrinsics Reference Manual (volume 5 of the X series) has extensive documentation on this. If you have access to a fax machine, I'll fax the relevant pages to you. As for focus, it looks like you need to specify translations for <FocusIn> and <FocusOut>, which somehow or other call XtSetKeyboardFocus(). The existing bindings are the focus-in() and focus-out() actions of the Text widget, which do nothing. Andy Piper wrote: -- Ben In order to save my hands, I am cutting back on my mail. I also write as succinctly as possible -- please don't be offended. If you send me mail, you _will_ get a response, but please be patient, especially for XEmacs-related mail. If you need an immediate response and it is not apparent in your message, please say so. Thanks for your understanding. See also http://www.666.com/ben/typing.html.

Andy> I'm being beaten by the Athena text widget. Specifically Andy> focus is not working how I would expect it to. For instance Andy> if I click on a text widget in XEmacs, the XEmacs frame Andy> doesn't lose the keyboard focus (this does work if using Andy> Motif). Thus if you type, characters go to the XEmacs frame Andy> instead of the text widget. Again this works under motif. Is this text widget a descendant of the currently focused frame (eg, in the gutter), or of another top-level window (eg, a dialog)? If the latter, be careful to respect user preferences about focus policy. There's nothing that's quite so annoying to me as a window which is automatically raised by the window manager when the mouse enters (I'm a focus-follows-mouse type) but whose focus is not set anywhere useful. Also, one of the things I hate most about Netscape is the fact that I have to click on text areas in forms to type into them. It would be really nice if "large" movements (PageUp, PageDown) could be sent to the browser window, while "small" movements (forward-char, eg) and text entry and modification would be sent to some automatically focused text field in the displayed form. Given that XEmacs's primary application is "text editor", you have to be careful about taking focus away from the editing window. Still, if an XEmacs frame is displaying a text widget that is _not_ a buffer window, some consideration should be given to finding ways to give it focus preference over the buffer windows (presumably the text widget is in some sense "more volatile" than a buffer, eg, in Custom where the buffer would be used to hold explanatory text that doesn't change and various customization widgets). This is evidently hard to do in a way that satisfies all the customers. So maybe I'm just dreaming.... -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules."