Bug 5284 - Toggling IMs in uim.el crashes uim-toolbar-applet
Summary: Toggling IMs in uim.el crashes uim-toolbar-applet
Status: CLOSED FIXED
Alias: None
Product: UIM
Classification: Unclassified
Component: helper: toolbar (show other bugs)
Version: unspecified
Hardware: x86 (IA32) Linux (All)
: high normal
Assignee: uim-bugs
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-12-08 19:16 UTC by Jae-hyeon Park
Modified: 2005-12-21 20:29 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
patch for uim-el-agent (6.83 KB, patch)
2005-12-09 04:26 UTC, Konosuke Watanabe
Details | Splinter Review

Description Jae-hyeon Park 2005-12-08 19:16:30 UTC
One can toggle between the default IM and an alternative IM by
pressing a hot key.  If I press this hot key once or twice in Emacs
with input method set to korean-byeoru-uim, the uim-toolbar-applet
crashes.  The alternative input method in uim preference was set to
anthy.  Uim.el was enabled with (require 'uim-leim) in ~/.emacs.

I am using uim snapshot as of 2005-12-05 on Debian etch.
Comment 1 Etsushi Kato 2005-12-08 20:09:02 UTC
With a casual check, it seems to be a problem with uim-el-agent.
It works fine with gtk+-immodule and uim-xim with toggle between byeoru and anthy.

Although I haven't checked the code of uim-el-agent, I guess it may be a problem
in encoding handling on im-switch.
Comment 2 Konosuke Watanabe 2005-12-09 01:41:09 UTC
As Etsushi guessed, uim-el-agent currently doesn't recognize
IM-switching triggered by hot-key pressing, and so a name and the encoding of 
Emacs are not updated. 
I guess that this may cause a crash or something.

Now, I'm writing a callback function for uim_set_configuration_changed_cb
to handle the IM-switching.
Please wait a moment.
Comment 3 Konosuke Watanabe 2005-12-09 04:26:01 UTC
Created attachment 4047 [details] [review]
patch for uim-el-agent

This is a patch for uim-el-agent which adds 
support for IM-switching with a hot key.

It can be applied to uim-el-0.0.6-beta3.
Comment 4 Etsushi Kato 2005-12-09 07:26:05 UTC
I appreciate your quick work, Konosuke.
The patch works fine for me.

I have another question.  uim-el in our repository is not updated to beta3.  Is
it worth while to update to the version for uim-1.0.0?

Thanks,
Comment 5 Jae-hyeon Park 2005-12-09 12:54:49 UTC
The patch works for me, too.  Great!

One minor point that I notice is that
the Emacs mode line is not updated immediately.
For example, if I was using two modes "byeoru[°¡]" and "anthy[ª¢]",
and if I toggle from anthy to byeoru, then
the mode line looks like "byeoru[亜]", which is
updated to "byeoru[°¡]" after one key stroke.
Comment 6 Konosuke Watanabe 2005-12-09 22:56:07 UTC
Thanks Jae-hyeon.

> One minor point that I notice is that
> the Emacs mode line is not updated immediately.

Yeah, this is known problem of current uim.el.

To introduce asynchronous transaction into the communication
between Emacs and uim-el-agent may improve this situation,
but I don't try it yet.
Comment 7 Jae-hyeon Park 2005-12-10 03:17:51 UTC
> > One minor point that I notice is that
> > the Emacs mode line is not updated immediately.
> 
> Yeah, this is known problem of current uim.el.
> 
> To introduce asynchronous transaction into the communication
> between Emacs and uim-el-agent may improve this situation,
> but I don't try it yet.

Thank you for your reply.
This is a separate issue, so I think the bug can be closed.
Comment 8 Etsushi Kato 2005-12-22 15:29:17 UTC
The IM label (emacs mode line) problem is fixed in r2682 (ported from uim-el
0.0.6-beta4), so close the bug.

Thanks,


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.