Loading ...
Sorry, an error occurred while loading the content.

Re: vim-GTK2 problem

Expand Messages
  • Daniel Elstner
    Hey, ... OK, thanks for investigating this. hardware_keycode = 65 won t cut it though, but XKeysymToKeycode() is about as easy ;-) Here s the patch:
    Message 1 of 3 , Feb 27, 2003
    • 0 Attachment
      Hey,

      On Don, 2003-02-27 at 10:47, Nam SungHyun wrote:
      > Hello,
      >
      > It was great with 'imhangul' module.
      > Now I see it does not work with XIM+ami.
      > Ami does not change its state to Hangul input mode when I type S-space.
      >
      > I just print the all 'key(event)' parameter in the xim_queue_key_press_event()
      > and found patch below fix the problem.

      OK, thanks for investigating this. hardware_keycode = 65 won't cut it
      though, but XKeysymToKeycode() is about as easy ;-) Here's the patch:

      http://regexxer.sourceforge.net/vim/vim-gtk2-20030227.patch.gz

      BTW with this patch, GTK+ 2 Vim now passes GDK_KEY_RELEASE events to the
      IM context as well. This makes the GTK+ Default IM module work properly
      (try SHIFT+CTRL+digits to enter a Unicode code point).

      Other changes are few new #ifndef HAVE_GTK2 around braindead code
      (sorry) that broke with GTK+ 2. In other words, the Find/Replace
      dialog(s) now work properly after the first use too.

      And, (hello Mikolaj :) mnemonic accelerators in dialogs can now be
      activated without holding the <Alt> key. I'm still not sure though
      whether that's really a wise thing to do. To stay on the safe side I
      made sure it's only done for pure buttons-only confirmation dialogs.

      > But now, when I change the input language mode to Hangul and input
      > first multibyte, there occurs next warning message.
      >
      > ** (vim:14734): WARNING **: Invalid change to preedit string,
      > first=0 length=1 (orig length == 0)

      Hmm. Well neither Vim nor GTK+ (AFAIK) change the preedit string on
      their own, so it could quite well be a bug in the IM module. At least
      it's not very robust.

      > This message does not occur for the first time (Hangul input mode).
      > It occurs 2nd, 3rd... seems forever.
      > I mean if 'AB' and 'CD' is multibyte, if I typed next in input mode:
      > eng<S-space>AB<S-space> eng<S-space>CD
      >
      > The error message occurs when I typed 'C'. And after that,
      > when I changed to Hangul input mode and input first multibyte,
      > the message always occurs.

      What are you typing exactly to get "AB" and "CD"? (I assume thanks to
      IM modules I could reproduce it myself using my qwertz keyboard).

      > It's just a warning. I can input Hangul correctly.

      Well, g_warning()s aren't harmless and usually indicate a more or less
      serious coding mistake somewhere. Otherwise it'd be quite unfriendly to
      print them to stderr if it were just spam...

      > I saw similar warning with gtkentry. And the problem was fixed.
      > from the gtk+/ChangeLog.pre-2-2. I believe next entry is it.
      >
      > Mon Dec 16 21:39:28 2002 Owen Taylor <otaylor@...>
      >
      > * gtk/gtkentry.c (gtk_entry_enter_text): Call
      > gtk_entry_set_position_internal() that takes a
      > new "reset_IM" parameter, so that we avoid the
      > problem where committing text would reset the
      > input method. (#74381, Kang Jeong-Hee)

      Hmm, I had a look at the GtkEntry code and couldn't find anything
      obviously related to the warning above. If it is indeed a problem in
      Vim and not the IM module I'll need to know more details to fix it.

      Regards,
      --Daniel
    • Nam SungHyun
      ... Any multibyte. In hangul input mode, you can type gks for both AB and CD . ... Check the GNOME bugzila #74381 (http://bugzilla.gnome.org). I think you
      Message 2 of 3 , Feb 27, 2003
      • 0 Attachment
        On 27 Feb 2003 14:07:49 +0100, Daniel Elstner wrote:
        >
        > On Don, 2003-02-27 at 10:47, Nam SungHyun wrote:
        >
        > > This message does not occur for the first time (Hangul input mode).
        > > It occurs 2nd, 3rd... seems forever.
        > > I mean if 'AB' and 'CD' is multibyte, if I typed next in input mode:
        > > eng<S-space>AB<S-space> eng<S-space>CD
        > >
        > > The error message occurs when I typed 'C'. And after that,
        > > when I changed to Hangul input mode and input first multibyte,
        > > the message always occurs.
        >
        > What are you typing exactly to get "AB" and "CD"?

        Any multibyte. In hangul input mode, you can type 'gks' for both
        "AB" and "CD".

        > > I saw similar warning with gtkentry. And the problem was fixed.
        > > from the gtk+/ChangeLog.pre-2-2. I believe next entry is it.
        > >
        > > Mon Dec 16 21:39:28 2002 Owen Taylor <otaylor@...>
        > >
        > > * gtk/gtkentry.c (gtk_entry_enter_text): Call
        > > gtk_entry_set_position_internal() that takes a
        > > new "reset_IM" parameter, so that we avoid the
        > > problem where committing text would reset the
        > > input method. (#74381, Kang Jeong-Hee)
        >
        > Hmm, I had a look at the GtkEntry code and couldn't find anything
        > obviously related to the warning above. If it is indeed a problem in
        > Vim and not the IM module I'll need to know more details to fix it.

        Check the GNOME bugzila #74381 (http://bugzilla.gnome.org).
        I think you can get a useful information from there.

        Regards,
        namsh
      • Daniel Elstner
        ... OK, I investigated this, and I m quite sure this is a problem of Ami itself. The GtkEntry code tries to get around it by avoiding IM resets whenever
        Message 3 of 3 , Mar 1, 2003
        • 0 Attachment
          On Fre, 2003-02-28 at 03:46, Nam SungHyun wrote:

          > > > I saw similar warning with gtkentry. And the problem was fixed.
          > > > from the gtk+/ChangeLog.pre-2-2. I believe next entry is it.
          > > >
          > > > Mon Dec 16 21:39:28 2002 Owen Taylor <otaylor@...>
          > > >
          > > > * gtk/gtkentry.c (gtk_entry_enter_text): Call
          > > > gtk_entry_set_position_internal() that takes a
          > > > new "reset_IM" parameter, so that we avoid the
          > > > problem where committing text would reset the
          > > > input method. (#74381, Kang Jeong-Hee)
          > >
          > > Hmm, I had a look at the GtkEntry code and couldn't find anything
          > > obviously related to the warning above. If it is indeed a problem in
          > > Vim and not the IM module I'll need to know more details to fix it.
          >
          > Check the GNOME bugzila #74381 (http://bugzilla.gnome.org).
          > I think you can get a useful information from there.

          OK, I investigated this, and I'm quite sure this is a problem of Ami
          itself. The GtkEntry code tries to get around it by avoiding IM resets
          whenever possible, but that's apparently not sufficient: try using the
          mouse to change the cursor position while preediting -- you'll get the
          same warning again.

          Nonetheless I tried to apply the same strategy of avoiding resets to the
          Vim code but that just broke lots of other things all over the place.
          However, in the end I found a kludge that seems to work:

          gtk_im_context_set_use_preedit(xic, FALSE);
          gtk_im_context_set_use_preedit(xic, TRUE);
          xim_set_focus(gui.in_focus);

          These silly 3 lines seem to make Ami handle the gtk_im_context_reset()
          gratiously. It seems to work even better than the GtkEntry work-around,
          plus it makes the Ami status window display the current language mode
          correctly. I'm still able to trigger the warning spuriously (and even
          make Ami hang) in a UTF-8 locale but that's probably another bug in
          Ami. LANG=ko_KR.eucKR works fine so far.

          As usual, here's the patch:

          http://regexxer.sourceforge.net/vim/vim-gtk2-20030302.patch.gz

          Another fixed problem: There seems to be a bug in the documentation of
          gtk_im_context_get_preedit_string(). It claims cursor_pos is a byte
          offset but in fact it's in characters (or code points). The GtkEntry
          code also interpretes cursor_pos as character index, and doing so in Vim
          fixed the mispositioned cursor when using Ami.

          BTW I had a look at the Ami sources but I refuse to work on code that's
          commented in Korean language :P

          Regards,
          --Daniel
        Your message has been successfully submitted and would be delivered to recipients shortly.