[Uim] uim-xim only works with japanese locale?

[Etsushi Kato]

On 2004/08/11, at 4:24, TOKUNAGA Hiroyuki wrote:

> 2. Sometimes unstable
>
>     I don't gain an understanding of when uim-xim causes segmentation
> fault, but sometimes it causes segv.

Hmm...  Do you have any backtrace report from users on this?

> 3. Written in C++
>
>     I'm not detailed in C++. (And, I think a basic library such as 
> input
> method library should be written in C, but uim-xim is a server, so in
> this case there's no problem about ABI.)
>    If I have to rewrite, I'll use only C. But that's not a problem if
> you do clean up.

Though I'm not C++ guru and just use it as better C, I think
C++ is suitable for XIM because it has several layers (XIC, XIM,
...), and several methods (on-the-spot, over-the-spot...).

> 4. It has some little bugs.
>
>    E.G. We cannot select texts by shift + arrow keys if uim-xim is
> enabled.  I tried but couldn't fix the bug. (I forgot other bugs, but
> they aren't so big.)

OK.  I'll check later.

> But, as a conclusion, if you feel that code of uim-xim is appropriate, 
> I
> have no objection.

Thanks.  Tabata-san, what do you think about using IMdKit?

>> Since current uim-xim creates some XimServer instances for
>> corresponding back-end engines, and requires user to set
>> XMODIFIERS=@im=uim-(engine) for each back-end to use.
>> In my patch, I changed using @server=uim only, which requires
>> XMODIFIERS=@im-uim.  And added command line option to
>> select default engine (like uim-xim --engine=prime, default is
>> anthy).
>
> It seems XMODIFIERS=@im=uim, rather than @im-uim, right?

Yep, XMODIFEIRS=@im=uim.  Also the patch I posted uses strlcat(), which 
is not portable in Linux.  I've fixed now.

So, is it OK to change XMODIFIERS name in next release of uim-xim?
Or should I avoid these changes?
-- 
Etsushi Kato
ekato at ees.hokudai.ac.jp