[Uim] A question about the space bar

[YamaKen]

At Thu, 08 Apr 2004 23:40:39 +0200,
david at start.no wrote:
> 
> YamaKen wrote:
> > Tokunaga-san, your patch caused unneeded effect for other IMs
> > (although the patch is a temporary solution), so I've rewritten
> > in safe way.
> > 
> > I've rewritten the code as same logic as Tokunaga-san's, I
> > thought, but I can't evaluate whether hangul IMs are working
> > correctly or not.  David-san, please test latest hangul.scm.
> 
> Sorry YamaKen, I meant to send that last post to the list.
> 
> If the new patch you're referring to is the one that causes the spacebar 
> to commit the preedit in hangul.scm, then I can only say that it works 
> for me.
> 
> I applied these changes to romaja.scm days ago and it worked perfectly 
> without affecting any other input methods. Just now I installed uim 
> 0.3.4.2, and it's *still* working perfectly without any sort of negative 
> effects.
> 
> So whatever errors you're experiencing on your system, I have a hard 
> time believing that they're caused by this patch. Especially since it 
> only applies to hangul.scm and doesn't affect the other files.

I said about not a expectation but the validated fact.

Other IMs such as uim-anthy are negatively affected via the
three define-key'ed variables although the previous patch
changed only hangul.scm.

> Anyway, I think it would be a mistake to apply a huge patch to fix 
> something that we don't know is broken yet. What sort of problems are 
> you experiencing exactly?

I actually experienced and solved following problems.

- Under uim-anthy, space key was unexpectedly causing immediate
  committing of preedit string in composing state (converting
  kana into kanji phase). Its proper behavior in composing state
  is to select candidates. This problem is caused by
  inappropriate global redefinition of generic-commit-key?. The
  redefinition adds unneeded committing role to space key
  globally, and overwrites candidate selection role for some
  IMs.

- Under uim-anthy, "<Control>p", "<Control>n" and vertical
  cursor keys were unexpectedly causing immediate committing of
  preedit string in composing state. Their proper behavior is to
  select candidates. This problem is caused by inappropriate
  global redefinition of generic-next-candidate-key? and
  generic-prev-candidate-key?. The redefinition globally removes
  special meaning from "<Control>p" and so on, so those keys are
  treated as ordinary key and causes unexpected committing.

Regards,
-------------------------------
YamaKen  yamaken at bp.iij4u.or.jp