Description of problem: iiim currently grabs ctrl modified key events. This means that standard keys like Ctrl-d etc can't be used in iiimf, or maybe it has to handle them specially? Steps to Reproduce: 1. enter some text in iiimf mode with ja or ko LE 2. move cursor back and press Ctrl-d 3. press Ctrl-a 4. press Ctrl-e 5. etc Actual results: 2. output for d event is inserted. 3. output for a event is inserted. 4. output for e event is inserted. Expected results: 2. character that cursor is on to be deleted. 3. the cursor to move to bol 4. the cursor to move to eol
should be fixed in 1:11.4-38
Sorry for the late response. I guess my original report was unclear, what I would like is really support for emacs-like bindings inside the input mode, not for control charatcers to be passed directly on to the underlining program. Eg now C-d exits gnome-terminal say, rather deleting the current pre-edit character to the right, and so on.
So do you want iiimf to support customizable keybinding?
[Customizable keybindings would also be a nice feature. :] After some private discussion, I think we have clarified the requirements better now. Dropping all key events is not the right behaviour - a minimal set of keys (say C-{a,e,d,g} should be caught at least and preferrably acted on in pre-edit mode), it would be nice to have bindings for C-{b,f,k,p,n} too as kinput2 canna and skkinput already have. So basically this is a rfe to get cannaLE is behave like kinput2, etc in pre-edit mode. (Personally I think other LEs should have similar behaviour implemented also, but I'm less familiar with CK input systems.)
this problem should be fixed in 12.0.1-4.svn1891 or later. although IIIMF doesn't have the customizable keybinding feature, the keybinding for Canna LE depends on Canna's keybinding now. so you can do that on Canna's configuration then. Anyway, I believe Canna LE has no regression for the keybinding.
Thanks, looks good to me now.
Do you support C-j too ?