Motif has historically been problematic on open source platforms (Linux, *BSD). Steve Baur had it completed deprecated for a long time, would just spit at bug reports with Linux+Motif. Jan> Does just "--with-xim=xlib" do the trick? There have been Jan> patches floating around to disable motif based xim completely Jan> because of its instability. XIM itself is a crock. It is full of crashes (that's how I got involved in XEmacs in the first place---it was easier to try to debug Martin's XIM code than the code in FSF 19.34 and 20.0---and it was internal to XF86, not Martin's code, as you might expect). That said, I _think_ XEmacs --with-xim=xlib is pretty stable now. I haven't had problems with it (but I normally use native Canna, not Canna+kinput2 -xim, for Japanese input; I'll switch for the next devel cycle). Anyway, I haven't seen any Japanese bitches about it, and I know a lot of Japanese are using XIM because they want to use the commercial input methods. _However_, if you have any Motif libraries at all, you may be _forced_ to build in the Motif XIM stuff. Motif's I18N model, especially the XIM stuff, varies markedly from Xlib's. -- 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."

On Mon, 26 Mar 2001 22:58:19 +0200, Jan Vroonhof said: That produces a so-far stable XEmacs. mule=no is also stable here. The odd part is that if Mule is compiled in along with Motif, it's a problem - even if the file being edited via gnuclient is strict printable us-ascii. Weird... /Valdis

Valdis> On Mon, 26 Mar 2001 22:58:19 +0200, Jan Vroonhof said: Valdis> That produces a so-far stable XEmacs. cool. Valdis> The odd part is that if Mule is compiled in along with Valdis> Motif, it's a problem - even if the file being edited via Valdis> gnuclient is strict printable us-ascii. Weird... Not really. The XIM implementation that Martin did _assumes_ you want to use XIM and tries to open an input method for each frame. This is sort of implicit in the XIM model. I have long wanted to have a lazy initialization that waited until input translation was actually requested, but XIM doesn't make that easy. -- 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."

Glynn Clements wrote: OK. Rebuilt Motif with debug info. This indicates that _XmImFreeShellData is trying to free the the IM data associated with the EmacsFrame, but this has already been destroyed. Comparing input-method-{xlib,motif}.c, I see that the xlib version installs a destroyCallback handler (XIM_delete_frame) which calls XDestroyIC(). OTOH, the Motif version doesn't; in fact, grepping for XmImUnregister turns up nothing. Applying the attached patch results in an xemacs which survives preliminary testing (ten repeats of "C-x 5 2 C-x 5 0"; the unpatched version dies on the first attempt). -- Glynn Clements <glynn(a)sensei.co.uk&gt; Index: src/input-method-motif.c =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/input-method-motif.c,v retrieving revision 1.9.2.3 diff -u -r1.9.2.3 input-method-motif.c --- src/input-method-motif.c 2000/01/26 12:34:03 1.9.2.3 +++ src/input-method-motif.c 2001/03/29 23:08:54 ＠＠ -94,6 +94,13 ＠＠ /* Nothing to do */ } +/* Callback for the deleting frame. */ +static void +XIM_delete_frame (Widget w, XtPointer client_data, XtPointer call_data) +{ + XmImUnregister ((Widget) client_data); +} + void XIM_init_frame (struct frame *f) { ＠＠ -152,6 +159,8 ＠＠ NULL); XmFontListEntryFree (&fontlistEntry); + + XtAddCallback (w, XmNdestroyCallback, XIM_delete_frame, (XtPointer) w); } void

GC> Comparing input-method-{xlib,motif}.c, I see that the xlib GC> version installs a destroyCallback handler (XIM_delete_frame) GC> which calls XDestroyIC(). OTOH, the Motif version doesn't; in GC> fact, grepping for XmImUnregister turns up nothing. mb> This surprises me (the original author of the code). mb> I very vaguely remember having used XmImUnregister somewhere, mb> 5 years ago. Your patch looks correct, but why has xim-motif mb> mostly worked the past 5 years? Anyway, whatever -- in your opinion as original author is this patch _safe_ to apply to 21.4? -- 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."

mb> Would I apply this fix to the code? Yes, given some mb> investigation of the history of input-method-motif.c and some I've done that. `less input-method-motif.c,v' shows that there never was a call to XmImUnregister() in that code, at least back to '97 or so, and that few changes have ever been made. Is there anything else worth looking for? mb> testing (which I won't do myself). Glynn? Valdis? et al...? I am not going to do it either, I don't have a convenient Motif platform available at the moment. If I don't hear from anybody right away, it'll be in my queue for 21.4.1 and I'll come knocking. :-) -- 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."