Re: Yiddish input method

[raphael cs uky edu (Raphael Finkel)]

> from Owen Taylor <otaylor redhat com>, Mar 19, Re: Yiddish input method      
>
> > I discovered that gtk+ does a context reset in places I think it
> > shouldn't.  Supposedly, gtk+ only does context reset when the user moves
> > the cursor to a new position by clicking somewhere.  But in an entry
> > widget, such as that used to elicit a file name, gtk+ is calling my context
> > reset routine after each keystroke, which confuses my input method.
> 
> Can you find out what is making reset get called? (Put a breakpoint, do a
> backtrace)

It looks like it is being called as a deep side-effect of the commit that my
code calls.

#0  0x4028ea54 in my_context_reset (context=0x8142988) at imyiddish.c:347
#1  0x4011f651 in gtk_im_context_reset (context=0x8142988)
    at gtkimcontext.c:374
#2  0x401215de in gtk_im_multicontext_reset (context=0x813a628)
    at gtkimmulticontext.c:322
#3  0x4011f651 in gtk_im_context_reset (context=0x813a628)
    at gtkimcontext.c:374
#4  0x401046e9 in gtk_entry_reset_im_context (entry=0x813a4f0)
    at gtkentry.c:2762
#5  0x40102c91 in gtk_entry_real_set_position (editable=0x813a4f0, position=2)
    at gtkentry.c:1729
#6  0x401002f2 in gtk_editable_set_position (editable=0x813a4f0, position=2)
    at gtkeditable.c:136
#7  0x40103bd8 in gtk_entry_enter_text (entry=0x813a4f0, str=0x8145a28 "�\234")
    at gtkentry.c:2305
#8  0x401039aa in gtk_entry_commit_cb (context=0x813a628, 
    str=0x8145a28 "�\234", entry=0x813a4f0) at gtkentry.c:2238
#9  0x403e978c in g_cclosure_marshal_VOID__STRING (closure=0x813a5d8, 
    return_value=0x0, n_param_values=2, param_values=0xbfffd12c, 
    invocation_hint=0xbfffd018, marshal_data=0x0) at gmarshal.c:496
#10 0x403d3e7e in g_closure_invoke (closure=0x813a5d8, return_value=0x0, 
    n_param_values=2, param_values=0xbfffd12c, invocation_hint=0xbfffd018)
    at gclosure.c:437
#11 0x403e81b4 in signal_emit_unlocked_R (node=0x808e7d0, detail=0, 
    instance=0x813a628, emission_return=0x0, instance_and_params=0xbfffd12c)
    at gsignal.c:2340
#12 0x403e69f1 in g_signal_emit_valist (instance=0x813a628, signal_id=129, 
    detail=0, var_args=0xbfffd380) at gsignal.c:2099
#13 0x403e744a in g_signal_emit_by_name (instance=0x813a628, 
    detailed_signal=0x4024e190 "commit") at gsignal.c:2167
#14 0x401217c9 in gtk_im_multicontext_commit_cb (slave=0x8142988, 
    str=0x8151ed0 "�\234", multicontext=0x813a628) at gtkimmulticontext.c:407
#15 0x403e978c in g_cclosure_marshal_VOID__STRING (closure=0x8143ae0, 
    return_value=0x0, n_param_values=2, param_values=0xbfffd6bc, 
    invocation_hint=0xbfffd5a8, marshal_data=0x0) at gmarshal.c:496
#16 0x403d3e7e in g_closure_invoke (closure=0x8143ae0, return_value=0x0, 
    n_param_values=2, param_values=0xbfffd6bc, invocation_hint=0xbfffd5a8)
    at gclosure.c:437
#17 0x403e81b4 in signal_emit_unlocked_R (node=0x808e7d0, detail=0, 
    instance=0x8142988, emission_return=0x0, instance_and_params=0xbfffd6bc)
    at gsignal.c:2340
#18 0x403e69f1 in g_signal_emit_valist (instance=0x8142988, signal_id=129, 
    detail=0, var_args=0xbfffd910) at gsignal.c:2099
#19 0x403e744a in g_signal_emit_by_name (instance=0x8142988, 
    detailed_signal=0x4028ed3f "commit") at gsignal.c:2167
#20 0x4028e9e1 in enqueue (string=0x4028ec5c "ל") at imyiddish.c:325

>   I'm not really sure what the issue you are trying to solve with the
>   delayed commit is ... it strikes me as a little odd to be able to
>   backspace through arbitrary amounts text and convert shin => sin, 
>   especially if you can't do the same thing when moving the cursor
>   around.

I am not delaying a commit; I am committing something on every keystroke, but
sometimes I need to go back and change what I have committed.  The result is a
very pleasant look and feel; you always see text that is correct with respect
to what you have entered so far.

Raphael