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

Re: VIM 7.2a.10 (GTK2, cygwin) weird cursor color problem

Expand Messages
  • SungHyun Nam
    Hello, ... $ echo $LANG $ echo $GTK_IM_MODULE hangul2 $ echo $XMODIFIERS $ ... I think LANG does not affect cygwin. Instead windows s current codepage(?)
    Message 1 of 18 , Jul 1, 2008
    • 0 Attachment
      Hello,

      My settings are:
      -------------------
      $ echo $LANG

      $ echo $GTK_IM_MODULE
      hangul2
      $ echo $XMODIFIERS

      $
      --------------------

      I think LANG does not affect cygwin. Instead windows's current
      codepage(?) affects cygwin. I use Korean version of windows which
      use CP949 codepage. Unix(or Linux) korean users would use
      'LANG=ko' (same as ko_KR, ko_KR.eucKR) or 'LANG=ko_KR.UTF-8'. I used
      'LANG=ko_KR.UTF-8' on Linux.

      And the 'imhangul' supports several modules (keyboard layout).
      $ cat /etc/gtk-2.0/gtk.immodules | grep hangul
      "/usr/lib/gtk-2.0/immodules/im-hangul.dll"
      "hangul2" "Hangul 2bul" "im-hangul" "/opt/share/locale" "ko"
      "hangul32" "Hangul 3bul 2bul-shifted" "im-hangul" "/opt/share/locale" ""
      "hangul39" "Hangul 3bul 390" "im-hangul" "/opt/share/locale" ""
      "hangul3f" "Hangul 3bul Final" "im-hangul" "/opt/share/locale" ""
      "hangul3s" "Hangul 3bul No-Shift" "im-hangul" "/opt/share/locale" ""
      "hangul3y" "Hangul 3bul Yetgeul" "im-hangul" "/opt/share/locale" ""

      Regards.
      namsh

      mattn wrote:
      > SungHyun Nam, more question.
      >
      > what $LANG?
      > what $GTK_IM_MODULE?
      > what $XMODIFIERS
      >
      > Thanks.
      >
      > On Wed, Jul 2, 2008 at 10:28 AM, SungHyun Nam <namsh@...>
      wrote:
      >> mattn wrote:
      >>> Hmm, it seems that current code was broken for japanese also.
      >>> I'll look into it later.
      >>>
      >>> SungHyun Nam, What IM do you use?
      >> I use 'imhangul', GTK2 im module.
      >> (svn://kldp.net/svnroot/imhangul/imhangul/trunk)
      >>
      >> I used nabi(XIM) and imhangul(GTK2 im module) on Linux. But, I
      >> could not install nabi on cygwin. So that, I cannot test xim
      >> stuff (no linux box here. :-( ).
      >>
      >> Regards,
      >> namsh
      >>
      >
      >
      >

      --~--~---------~--~----~------------~-------~--~----~
      You received this message from the "vim_dev" maillist.
      For more information, visit http://www.vim.org/maillist.php
      -~----------~----~----~----~------~----~------~--~---
    • mattn
      Hi Do you set imak? ... -- - Yasuhiro Matsumoto --~--~---------~--~----~------------~-------~--~----~ You received this message from the vim_dev maillist.
      Message 2 of 18 , Jul 1, 2008
      • 0 Attachment
        Hi

        Do you set imak?

        On Wed, Jul 2, 2008 at 1:23 PM, SungHyun Nam <goweol@...> wrote:
        > Hello,
        >
        > My settings are:
        > -------------------
        > $ echo $LANG
        >
        > $ echo $GTK_IM_MODULE
        > hangul2
        > $ echo $XMODIFIERS
        >
        > $
        > --------------------
        >
        > I think LANG does not affect cygwin. Instead windows's current
        > codepage(?) affects cygwin. I use Korean version of windows which
        > use CP949 codepage. Unix(or Linux) korean users would use
        > 'LANG=ko' (same as ko_KR, ko_KR.eucKR) or 'LANG=ko_KR.UTF-8'. I used
        > 'LANG=ko_KR.UTF-8' on Linux.
        >
        > And the 'imhangul' supports several modules (keyboard layout).
        > $ cat /etc/gtk-2.0/gtk.immodules | grep hangul
        > "/usr/lib/gtk-2.0/immodules/im-hangul.dll"
        > "hangul2" "Hangul 2bul" "im-hangul" "/opt/share/locale" "ko"
        > "hangul32" "Hangul 3bul 2bul-shifted" "im-hangul" "/opt/share/locale" ""
        > "hangul39" "Hangul 3bul 390" "im-hangul" "/opt/share/locale" ""
        > "hangul3f" "Hangul 3bul Final" "im-hangul" "/opt/share/locale" ""
        > "hangul3s" "Hangul 3bul No-Shift" "im-hangul" "/opt/share/locale" ""
        > "hangul3y" "Hangul 3bul Yetgeul" "im-hangul" "/opt/share/locale" ""
        >
        > Regards.
        > namsh
        >
        > mattn wrote:
        >> SungHyun Nam, more question.
        >>
        >> what $LANG?
        >> what $GTK_IM_MODULE?
        >> what $XMODIFIERS
        >>
        >> Thanks.
        >>
        >> On Wed, Jul 2, 2008 at 10:28 AM, SungHyun Nam <namsh@...> wrote:
        >>> mattn wrote:
        >>>> Hmm, it seems that current code was broken for japanese also.
        >>>> I'll look into it later.
        >>>>
        >>>> SungHyun Nam, What IM do you use?
        >>> I use 'imhangul', GTK2 im module.
        >>> (svn://kldp.net/svnroot/imhangul/imhangul/trunk)
        >>>
        >>> I used nabi(XIM) and imhangul(GTK2 im module) on Linux. But, I
        >>> could not install nabi on cygwin. So that, I cannot test xim
        >>> stuff (no linux box here. :-( ).
        >>>
        >>> Regards,
        >>> namsh
        >>>
        >>
        >>
        >>
        >



        --
        - Yasuhiro Matsumoto

        --~--~---------~--~----~------------~-------~--~----~
        You received this message from the "vim_dev" maillist.
        For more information, visit http://www.vim.org/maillist.php
        -~----------~----~----~----~------~----~------~--~---
      • Tony Mechelynck
        ... [...] To see how locales are set inside Vim at any specific moment, use ... with no arguments. This will show you what Vim uses internally, as set on Linux
        Message 3 of 18 , Jul 1, 2008
        • 0 Attachment
          On 02/07/08 06:23, SungHyun Nam wrote:
          > Hello,
          >
          > My settings are:
          > -------------------
          > $ echo $LANG
          >
          > $ echo $GTK_IM_MODULE
          > hangul2
          > $ echo $XMODIFIERS
          >
          > $
          > --------------------
          >
          > I think LANG does not affect cygwin. Instead windows's current
          > codepage(?) affects cygwin. I use Korean version of windows which
          > use CP949 codepage. Unix(or Linux) korean users would use
          > 'LANG=ko' (same as ko_KR, ko_KR.eucKR) or 'LANG=ko_KR.UTF-8'. I used
          > 'LANG=ko_KR.UTF-8' on Linux.
          [...]

          To see how locales are set inside Vim at any specific moment, use

          :language

          with no arguments. This will show you what Vim uses internally, as set
          on Linux from $LANG, $LC_ALL, $LC_CTYPE, $LC_MESSAGES, etc.; on Windows
          from your "country settings" (or whatever they are called); and on all
          platforms by using the various "setting" variants of the ":language"
          command.


          Best regards,
          Tony.
          --
          It's always darkest just before it gets pitch black.

          --~--~---------~--~----~------------~-------~--~----~
          You received this message from the "vim_dev" maillist.
          For more information, visit http://www.vim.org/maillist.php
          -~----------~----~----~----~------~----~------~--~---
        • SungHyun Nam
          ... The :lang result was C for various LANG settings below: $ LANG=ko_KR.eucKR gvim $ LANG=ko_KR.UTF-8 gvim $ LANG= gvim And gvim uses/displays translated
          Message 4 of 18 , Jul 2, 2008
          • 0 Attachment
            Tony Mechelynck wrote:
            > On 02/07/08 06:23, SungHyun Nam wrote:
            >> Hello,
            >>
            >> My settings are:
            >> -------------------
            >> $ echo $LANG
            >>
            >> $ echo $GTK_IM_MODULE
            >> hangul2
            >> $ echo $XMODIFIERS
            >>
            >> $
            >> --------------------
            >>
            >> I think LANG does not affect cygwin. Instead windows's current
            >> codepage(?) affects cygwin. I use Korean version of windows which
            >> use CP949 codepage. Unix(or Linux) korean users would use
            >> 'LANG=ko' (same as ko_KR, ko_KR.eucKR) or 'LANG=ko_KR.UTF-8'. I used
            >> 'LANG=ko_KR.UTF-8' on Linux.
            > [...]
            >
            > To see how locales are set inside Vim at any specific moment, use
            >
            > :language
            >
            > with no arguments. This will show you what Vim uses internally, as set
            > on Linux from $LANG, $LC_ALL, $LC_CTYPE, $LC_MESSAGES, etc.; on Windows
            > from your "country settings" (or whatever they are called); and on all
            > platforms by using the various "setting" variants of the ":language"
            > command.

            The ':lang' result was "C" for various LANG settings below:
            $ LANG=ko_KR.eucKR gvim
            $ LANG=ko_KR.UTF-8 gvim
            $ LANG= gvim

            And gvim uses/displays translated message when I set 'LANG' to
            ko_KR.eucKR or ko_KR.UTF-8.

            Regards,
            namsh

            --~--~---------~--~----~------------~-------~--~----~
            You received this message from the "vim_dev" maillist.
            For more information, visit http://www.vim.org/maillist.php
            -~----------~----~----~----~------~----~------~--~---
          • mattn
            At the first, I explain the current state of Vim and IM. Vim is supporting some GUI interface. * Windows * Mac * Xaw * GTK * etc... And Vim is supporting some
            Message 5 of 18 , Jul 2, 2008
            • 0 Attachment
              At the first, I explain the current state of Vim and IM.
              Vim is supporting some GUI interface.

              * Windows
              * Mac
              * Xaw
              * GTK
              * etc...

              And Vim is supporting some IM on the above.

              * Windows - WindowsIME
              * Mac - MacIME
              * Xaw - XIM
              * GTK - gtkimmodule
              * etc...

              WindowsIME, MacIME, XIM are able to catch a trigger which IM was toggled.
              ex: IM is on, IM is off

              But gtkimmodule can't same. gtkimmodule does not provide API like a following.

              * regist event handler which can catch the IM toggle.
              * get current IM state.

              Most IM on gtkimmodule use key sniffer for the catching IM's activation-key.
              and client application can't know how key was trigger event. so far, vim
              pretended that IM is active because it sent 'imactivatekey'. but it was big
              workaround or ad-hock logic. I know that vim using gtkimmodule can't support
              CursorIM correctly. The thing that it work without lies is only following.

              * WindowsIME, MacIME, XIM work as before.
              * vim-gtk2 change cursor to CursorIM only between preedit_start and preedit_end.

              Unfortunately, Some gtkimmodule emit preedit_end when word was commited
              while state of preediting.
              And some gtkimmodule don't emit preedit_start when user press the
              activation-key and when user type leading character of preediting word.

              I know that vim is only application that try to change IM status.

              I think that vim-gtk2 should not support CursorIM like other's behavior.
              Or, CursorIM should be changed while the preediting characters are exist.

              Bram, how do you think about?

              If you accept above changes, I'll make a patch of fixing this.
              (I have already the patch roughly)

              --
              - Yasuhiro Matsumoto

              --~--~---------~--~----~------------~-------~--~----~
              You received this message from the "vim_dev" maillist.
              For more information, visit http://www.vim.org/maillist.php
              -~----------~----~----~----~------~----~------~--~---
            • Tony Mechelynck
              ... Maybe you should try another IM module with your Vim+GTK2 (as long as it supports one or more of the three input styles other than OnTheSpot)? I m not sure
              Message 6 of 18 , Jul 2, 2008
              • 0 Attachment
                On 02/07/08 11:50, mattn wrote:
                > At the first, I explain the current state of Vim and IM.
                > Vim is supporting some GUI interface.
                >
                > * Windows
                > * Mac
                > * Xaw
                > * GTK
                > * etc...
                >
                > And Vim is supporting some IM on the above.
                >
                > * Windows - WindowsIME
                > * Mac - MacIME
                > * Xaw - XIM
                > * GTK - gtkimmodule
                > * etc...
                >
                > WindowsIME, MacIME, XIM are able to catch a trigger which IM was toggled.
                > ex: IM is on, IM is off
                >
                > But gtkimmodule can't same. gtkimmodule does not provide API like a following.
                >
                > * regist event handler which can catch the IM toggle.
                > * get current IM state.
                >
                > Most IM on gtkimmodule use key sniffer for the catching IM's activation-key.
                > and client application can't know how key was trigger event. so far, vim
                > pretended that IM is active because it sent 'imactivatekey'. but it was big
                > workaround or ad-hock logic. I know that vim using gtkimmodule can't support
                > CursorIM correctly. The thing that it work without lies is only following.
                >
                > * WindowsIME, MacIME, XIM work as before.
                > * vim-gtk2 change cursor to CursorIM only between preedit_start and preedit_end.
                >
                > Unfortunately, Some gtkimmodule emit preedit_end when word was commited
                > while state of preediting.
                > And some gtkimmodule don't emit preedit_start when user press the
                > activation-key and when user type leading character of preediting word.
                >
                > I know that vim is only application that try to change IM status.
                >
                > I think that vim-gtk2 should not support CursorIM like other's behavior.
                > Or, CursorIM should be changed while the preediting characters are exist.
                >
                > Bram, how do you think about?
                >
                > If you accept above changes, I'll make a patch of fixing this.
                > (I have already the patch roughly)
                >

                Maybe you should try another IM module with your Vim+GTK2 (as long as it
                supports one or more of the three input styles other than OnTheSpot)?
                I'm not sure what is best for your language but scim looks quite
                configurable.


                Best regards,
                Tony.
                --
                hundred-and-one symptoms of being an internet addict:
                39. You move into a new house and decide to Netscape before you landscape.

                --~--~---------~--~----~------------~-------~--~----~
                You received this message from the "vim_dev" maillist.
                For more information, visit http://www.vim.org/maillist.php
                -~----------~----~----~----~------~----~------~--~---
              • SungHyun Nam
                ... toggled. ... word. ... I hope vim-gtk2 supports CursorIM. ... And my patch exactly did it? did I misunderstood? ... BTW, was this problem caused by
                Message 7 of 18 , Jul 2, 2008
                • 0 Attachment
                  Tony Mechelynck wrote:
                  > On 02/07/08 11:50, mattn wrote:
                  >> At the first, I explain the current state of Vim and IM.
                  >> Vim is supporting some GUI interface.
                  >>
                  >> * Windows
                  >> * Mac
                  >> * Xaw
                  >> * GTK
                  >> * etc...
                  >>
                  >> And Vim is supporting some IM on the above.
                  >>
                  >> * Windows - WindowsIME
                  >> * Mac - MacIME
                  >> * Xaw - XIM
                  >> * GTK - gtkimmodule
                  >> * etc...
                  >>
                  >> WindowsIME, MacIME, XIM are able to catch a trigger which IM was
                  toggled.
                  >> ex: IM is on, IM is off
                  >>
                  >> But gtkimmodule can't same. gtkimmodule does not provide API like a
                  >> following.
                  >>
                  >> * regist event handler which can catch the IM toggle.
                  >> * get current IM state.
                  >>
                  >> Most IM on gtkimmodule use key sniffer for the catching IM's
                  >> activation-key.
                  >> and client application can't know how key was trigger event. so far, vim
                  >> pretended that IM is active because it sent 'imactivatekey'. but it
                  >> was big
                  >> workaround or ad-hock logic. I know that vim using gtkimmodule can't
                  >> support
                  >> CursorIM correctly. The thing that it work without lies is only
                  >> following.
                  >>
                  >> * WindowsIME, MacIME, XIM work as before.
                  >> * vim-gtk2 change cursor to CursorIM only between preedit_start and
                  >> preedit_end.
                  >>
                  >> Unfortunately, Some gtkimmodule emit preedit_end when word was commited
                  >> while state of preediting.
                  >> And some gtkimmodule don't emit preedit_start when user press the
                  >> activation-key and when user type leading character of preediting
                  word.
                  >>
                  >> I know that vim is only application that try to change IM status.
                  >>
                  >> I think that vim-gtk2 should not support CursorIM like other's behavior.

                  I hope vim-gtk2 supports CursorIM.

                  >> Or, CursorIM should be changed while the preediting characters are
                  >> exist.

                  And my patch exactly did it? did I misunderstood?

                  >> Bram, how do you think about?
                  >>
                  >> If you accept above changes, I'll make a patch of fixing this.
                  >> (I have already the patch roughly)

                  BTW, was this problem caused by CursorIM supporting?
                  Bram said:
                  Looks like this is the usual mixup with using one flag for
                  more than one thing. Perhaps we also need a
                  "preedit_is_active" flag?
                  Please think about it if you didn't.

                  > Maybe you should try another IM module with your Vim+GTK2 (as long as it
                  > supports one or more of the three input styles other than OnTheSpot)?
                  > I'm not sure what is best for your language but scim looks quite
                  > configurable.


                  --~--~---------~--~----~------------~-------~--~----~
                  You received this message from the "vim_dev" maillist.
                  For more information, visit http://www.vim.org/maillist.php
                  -~----------~----~----~----~------~----~------~--~---
                • mattn
                  On Thu, Jul 3, 2008 at 8:41 AM, SungHyun Nam wrote: ... Yes. I don t think the removing all supports of CursorIM on gtk2. It s a
                  Message 8 of 18 , Jul 2, 2008
                  • 0 Attachment
                    On Thu, Jul 3, 2008 at 8:41 AM, SungHyun Nam <goweol@...> wrote:
                    <snip>
                    > >> Or, CursorIM should be changed while the preediting characters are
                    > >> exist.
                    >
                    > And my patch exactly did it? did I misunderstood?

                    Yes. I don't think the removing all supports of CursorIM on gtk2. It's
                    a partial supports.
                    I tried imhangle. vim can't get status of IM with imhangle too because
                    gtkimmodule does not provide API which can get status.
                    Certainly, when you type 's-space' on imhangul, vim change the cursor
                    to CursorIM. but im may not be active.

                    (1) imhangul
                    for example, you want to input multi-byte "[A1][A2]".
                    * A1: need to type a1# (example)
                    * A2: need to type a2#

                    you will type "<s-space>a1#a2#<s-space>". then gtkimmodule emit
                    following events.

                    <s-space> : preedit_start
                    a : preedit_change
                    1 : preedit_change
                    # : commit
                    a : preedit_change
                    2 : preedit_change
                    # : commit
                    <s-space> : preedit_end

                    (2) scim or uim
                    for example, japanese want to input multi-byte "[A1][A2]".
                    * A1: need to type a1# (example)
                    * A2: need to type a2#

                    japanese will type ...
                    <s-space>
                    a1#<space><cr>
                    a2#<space><cr>
                    <s-space>

                    gtkimmodule emit following events.

                    <s-space> : no events
                    a : preedit_start, preedit_change
                    1 : preedit_change
                    # : preedit_change
                    <space> : preedit_change
                    <cr> : commit, preedit_change, preedit_end
                    a : preedit_start, preedit_change
                    2 : preedit_change
                    # : preedit_change
                    <space> : preedit_change
                    <cr> : commit, preedit_change, preedit_end
                    <s-space> : no events

                    Thus, the range of "preedit_start" and "preedit_end" does not mean
                    that IM is active.

                    i.e. vim-gtk2 can't treat status of IM perfectly.

                    > >> Bram, how do you think about?
                    > >>
                    > >> If you accept above changes, I'll make a patch of fixing this.
                    > >> (I have already the patch roughly)
                    >
                    > BTW, was this problem caused by CursorIM supporting?
                    > Bram said:
                    > Looks like this is the usual mixup with using one flag for
                    > more than one thing. Perhaps we also need a
                    > "preedit_is_active" flag?
                    > Please think about it if you didn't.

                    Yes, my solution is the fixing of above. CursorIM is getting status of
                    IM from "im_get_status()".
                    But vim should set status of preediting for CursorIM. My roughly patch
                    is fixing this.

                    --
                    - Yasuhiro Matsumoto

                    --~--~---------~--~----~------------~-------~--~----~
                    You received this message from the "vim_dev" maillist.
                    For more information, visit http://www.vim.org/maillist.php
                    -~----------~----~----~----~------~----~------~--~---
                  • SungHyun Nam
                    ... I am somewhat confused. Did you check my patch I sent out? I read your mail that your patch is same as my patch.
                    Message 9 of 18 , Jul 2, 2008
                    • 0 Attachment
                      mattn wrote:
                      >
                      > Yes, my solution is the fixing of above. CursorIM is getting status of
                      > IM from "im_get_status()".
                      > But vim should set status of preediting for CursorIM. My roughly patch
                      > is fixing this.

                      I am somewhat confused. Did you check my patch I sent out?
                      I read your mail that your patch is same as my patch.
                      http://permalink.gmane.org/gmane.editors.vim.devel/20376

                      Or could you include your patch? At least, people including me can
                      verify it works fine for them.

                      Regards,
                      namsh

                      --~--~---------~--~----~------------~-------~--~----~
                      You received this message from the "vim_dev" maillist.
                      For more information, visit http://www.vim.org/maillist.php
                      -~----------~----~----~----~------~----~------~--~---
                    • mattn
                      ... Ah, it s similar. sorry i didn t see your patch. X-( And my patch include other fix. vim should be disconnect handler of preediting signal. Some IM which i
                      Message 10 of 18 , Jul 2, 2008
                      • 0 Attachment
                        On Thu, Jul 3, 2008 at 1:24 PM, SungHyun Nam <goweol@...> wrote:
                        >
                        > mattn wrote:
                        > >
                        > > Yes, my solution is the fixing of above. CursorIM is getting status of
                        > > IM from "im_get_status()".
                        > > But vim should set status of preediting for CursorIM. My roughly patch
                        > > is fixing this.
                        >
                        > I am somewhat confused. Did you check my patch I sent out?
                        > I read your mail that your patch is same as my patch.
                        > http://permalink.gmane.org/gmane.editors.vim.devel/20376
                        >
                        > Or could you include your patch? At least, people including me can
                        > verify it works fine for them.
                        >
                        > Regards,
                        > namsh
                        >
                        > >
                        >

                        Ah, it's similar. sorry i didn't see your patch. X-(
                        And my patch include other fix.
                        vim should be disconnect handler of preediting signal.
                        Some IM which i tried was crash with typing <ESC>.

                        Thanks.

                        --
                        - Yasuhiro Matsumoto


                        Index: gui.c
                        ===================================================================
                        --- gui.c (revision 1092)
                        +++ gui.c (working copy)
                        @@ -958,7 +958,13 @@
                        static int iid;
                        guicolor_T fg, bg;

                        - if (im_get_status())
                        + if (
                        +#ifdef HAVE_GTK2
                        + im_is_preediting()
                        +#else
                        + im_get_status()
                        +#endif
                        + )
                        {
                        iid = syn_name2id((char_u *)"CursorIM");
                        if (iid > 0)
                        Index: mbyte.c
                        ===================================================================
                        --- mbyte.c (revision 1092)
                        +++ mbyte.c (working copy)
                        @@ -3458,6 +3458,9 @@
                        static int im_preedit_trailing = 0; /* number of characters after cursor */

                        static unsigned long im_commit_handler_id = 0;
                        +static unsigned long im_changed_handler_id = 0;
                        +static unsigned long im_start_handler_id = 0;
                        +static unsigned long im_end_handler_id = 0;
                        static unsigned int im_activatekey_keyval = GDK_VoidSymbol;
                        static unsigned int im_activatekey_state = 0;

                        @@ -3942,17 +3945,20 @@
                        g_return_if_fail(gui.drawarea != NULL);
                        g_return_if_fail(gui.drawarea->window != NULL);

                        - xic = gtk_im_multicontext_new();
                        - g_object_ref(xic);
                        + if (!xic)
                        + {
                        + xic = gtk_im_multicontext_new();
                        + g_object_ref(xic);

                        - im_commit_handler_id = g_signal_connect(G_OBJECT(xic), "commit",
                        - G_CALLBACK(&im_commit_cb), NULL);
                        - g_signal_connect(G_OBJECT(xic), "preedit_changed",
                        - G_CALLBACK(&im_preedit_changed_cb), NULL);
                        - g_signal_connect(G_OBJECT(xic), "preedit_start",
                        - G_CALLBACK(&im_preedit_start_cb), NULL);
                        - g_signal_connect(G_OBJECT(xic), "preedit_end",
                        - G_CALLBACK(&im_preedit_end_cb), NULL);
                        + im_commit_handler_id = g_signal_connect(G_OBJECT(xic), "commit",
                        + G_CALLBACK(&im_commit_cb), NULL);
                        + im_changed_handler_id = g_signal_connect(G_OBJECT(xic), "preedit_changed",
                        + G_CALLBACK(&im_preedit_changed_cb), NULL);
                        + im_start_handler_id = g_signal_connect(G_OBJECT(xic), "preedit_start",
                        + G_CALLBACK(&im_preedit_start_cb), NULL);
                        + im_end_handler_id = g_signal_connect(G_OBJECT(xic), "preedit_end",
                        + G_CALLBACK(&im_preedit_end_cb), NULL);
                        + }

                        gtk_im_context_set_client_window(xic, gui.drawarea->window);
                        }
                        @@ -3966,12 +3972,19 @@

                        if (xic != NULL)
                        {
                        + if (im_commit_handler_id) g_signal_handler_disconnect(G_OBJECT(xic),
                        im_commit_handler_id);
                        + if (im_changed_handler_id)
                        g_signal_handler_disconnect(G_OBJECT(xic), im_changed_handler_id);
                        + if (im_start_handler_id) g_signal_handler_disconnect(G_OBJECT(xic),
                        im_start_handler_id);
                        + if (im_end_handler_id) g_signal_handler_disconnect(G_OBJECT(xic),
                        im_end_handler_id);
                        gtk_im_context_focus_out(xic);
                        g_object_unref(xic);
                        xic = NULL;
                        }
                        im_is_active = FALSE;
                        im_commit_handler_id = 0;
                        + im_changed_handler_id = 0;
                        + im_start_handler_id = 0;
                        + im_end_handler_id = 0;
                        preedit_start_col = MAXCOL;
                        xim_has_preediting = FALSE;
                        }

                        --~--~---------~--~----~------------~-------~--~----~
                        You received this message from the "vim_dev" maillist.
                        For more information, visit http://www.vim.org/maillist.php
                        -~----------~----~----~----~------~----~------~--~---
                      • SungHyun Nam
                        Hello, First of all, your patch for mbyte.c is totally different for this thread. You could send it with different bug report. It seems your patch for mbyte.c
                        Message 11 of 18 , Jul 3, 2008
                        • 0 Attachment
                          Hello,

                          First of all, your patch for mbyte.c is totally different for this
                          thread. You could send it with different bug report.
                          It seems your patch for mbyte.c is fine to me though I test it not
                          much.

                          Added comment below is only for CursorIM problem.

                          mattn wrote:
                          > On Thu, Jul 3, 2008 at 1:24 PM, SungHyun Nam <goweol@...> wrote:
                          >> mattn wrote:
                          >> >
                          >> > Yes, my solution is the fixing of above. CursorIM is getting
                          status of
                          >> > IM from "im_get_status()".
                          >> > But vim should set status of preediting for CursorIM. My roughly
                          patch
                          >> > is fixing this.
                          >>
                          >> I am somewhat confused. Did you check my patch I sent out?
                          >> I read your mail that your patch is same as my patch.
                          >> http://permalink.gmane.org/gmane.editors.vim.devel/20376
                          >>
                          >> Or could you include your patch? At least, people including me can
                          >> verify it works fine for them.
                          >
                          > Ah, it's similar. sorry i didn't see your patch. X-(
                          > And my patch include other fix.
                          > vim should be disconnect handler of preediting signal.
                          > Some IM which i tried was crash with typing <ESC>.

                          Hmm, it's similar and very small, but has glitch(?).
                          With your patch, 'CursorIM' color is NOT displayed immediately
                          after typing 'imak'. Because actual preediting is not yet started.
                          'CursorIM' color is displayed after I typed first multibyte
                          character. So that, if I typed 'imak' (with no further input) and
                          do something in other window, and come back, I can think current
                          input mode is English.

                          I suggest a patch below for the CursorIM problem:
                          Side-note:
                          The patch below also includes patch for command-line window
                          message. 'INSERT' vs 'IM INSERT' message now synchronized to
                          'Cursor' vs. 'CursorIM' color. I doubt 'b_p_iminsert' check
                          is really needed in screen.c. I never typed 'Ctrl-^' so that
                          b_p_iminsert is never have B_IMODE_IM for me.
                          If it's not acceptable, I can remove it from the patch.

                          Is this patch acceptable?

                          Regards,

                          diff --git a/src/gui.c b/src/gui.c
                          index 09c3027..decb0fb 100644
                          --- a/src/gui.c
                          +++ b/src/gui.c
                          @@ -958,7 +958,13 @@ gui_update_cursor(force, clear_selection)
                          static int iid;
                          guicolor_T fg, bg;

                          - if (im_get_status())
                          + if (
                          +#ifdef HAVE_GTK2
                          + preedit_get_status()
                          +#else
                          + im_get_status()
                          +#endif
                          + )
                          {
                          iid = syn_name2id((char_u *)"CursorIM");
                          if (iid > 0)
                          diff --git a/src/mbyte.c b/src/mbyte.c
                          index d6edf20..59c2ff8 100644
                          --- a/src/mbyte.c
                          +++ b/src/mbyte.c
                          @@ -3454,6 +3454,7 @@ init_preedit_start_col(void)
                          # if defined(HAVE_GTK2) && !defined(PROTO)

                          static int im_is_active = FALSE; /* IM is enabled for current
                          mode */
                          +static int preedit_is_active = FALSE;
                          static int im_preedit_cursor = 0; /* cursor offset in characters
                          */
                          static int im_preedit_trailing = 0; /* number of characters after
                          cursor */

                          @@ -3686,7 +3687,9 @@ im_preedit_start_cb(GtkIMContext *context,
                          gpointer data)
                          #endif

                          im_is_active = TRUE;
                          + preedit_is_active = TRUE;
                          gui_update_cursor(TRUE, FALSE);
                          + im_show_info();
                          }

                          /*
                          @@ -3710,6 +3713,7 @@ im_preedit_end_cb(GtkIMContext *context, gpointer
                          data)
                          * switched off unintentionally. */
                          im_is_active = FALSE;
                          #endif
                          + preedit_is_active = FALSE;
                          gui_update_cursor(TRUE, FALSE);
                          im_show_info();
                          }
                          @@ -4283,6 +4287,12 @@ im_get_status(void)
                          return im_is_active;
                          }

                          + int
                          +preedit_get_status(void)
                          +{
                          + return preedit_is_active;
                          +}
                          +
                          # else /* !HAVE_GTK2 */

                          static int xim_is_active = FALSE; /* XIM should be active in the current
                          diff --git a/src/proto/mbyte.pro b/src/proto/mbyte.pro
                          index ef11dc7..cac9ba8 100644
                          --- a/src/proto/mbyte.pro
                          +++ b/src/proto/mbyte.pro
                          @@ -82,6 +82,7 @@ void xim_init __ARGS((void));
                          void im_shutdown __ARGS((void));
                          int xim_get_status_area_height __ARGS((void));
                          int im_get_status __ARGS((void));
                          +int preedit_get_status __ARGS((void));
                          int im_is_preediting __ARGS((void));
                          int convert_setup __ARGS((vimconv_T *vcp, char_u *from, char_u *to));
                          int convert_input __ARGS((char_u *ptr, int len, int maxlen));
                          diff --git a/src/screen.c b/src/screen.c
                          index 78dd277..ea15338 100644
                          --- a/src/screen.c
                          +++ b/src/screen.c
                          @@ -8855,8 +8855,13 @@ showmode()
                          {
                          MSG_PUTS_ATTR("--", attr);
                          #if defined(FEAT_XIM)
                          - if (xic != NULL && im_get_status() && !p_imdisable
                          - && curbuf->b_p_iminsert == B_IMODE_IM)
                          + if (
                          +#ifdef HAVE_GTK2
                          + preedit_get_status()
                          +#else
                          + im_get_status()
                          +#endif
                          + )
                          # ifdef HAVE_GTK2 /* most of the time, it's not XIM being used */
                          MSG_PUTS_ATTR(" IM", attr);
                          # else

                          --~--~---------~--~----~------------~-------~--~----~
                          You received this message from the "vim_dev" maillist.
                          For more information, visit http://www.vim.org/maillist.php
                          -~----------~----~----~----~------~----~------~--~---
                        • mattn
                          ... yes, offcause. :-) ... Ok. It seems good for me. Your patch does not break any behavior of current vim. And your patch provide better solution for
                          Message 12 of 18 , Jul 3, 2008
                          • 0 Attachment
                            On Thu, Jul 3, 2008 at 4:46 PM, SungHyun Nam <goweol@...> wrote:
                            > Hello,
                            >
                            > First of all, your patch for mbyte.c is totally different for this
                            > thread. You could send it with different bug report.
                            > It seems your patch for mbyte.c is fine to me though I test it not
                            > much.

                            yes, offcause. :-)

                            > Added comment below is only for CursorIM problem.
                            > Hmm, it's similar and very small, but has glitch(?).
                            > With your patch, 'CursorIM' color is NOT displayed immediately
                            > after typing 'imak'. Because actual preediting is not yet started.
                            > 'CursorIM' color is displayed after I typed first multibyte
                            > character. So that, if I typed 'imak' (with no further input) and
                            > do something in other window, and come back, I can think current
                            > input mode is English.
                            >
                            > I suggest a patch below for the CursorIM problem:
                            > Side-note:
                            > The patch below also includes patch for command-line window
                            > message. 'INSERT' vs 'IM INSERT' message now synchronized to
                            > 'Cursor' vs. 'CursorIM' color. I doubt 'b_p_iminsert' check
                            > is really needed in screen.c. I never typed 'Ctrl-^' so that
                            > b_p_iminsert is never have B_IMODE_IM for me.
                            > If it's not acceptable, I can remove it from the patch.
                            >
                            > Is this patch acceptable?
                            <snip>

                            Ok. It seems good for me.
                            Your patch does not break any behavior of current vim. And your patch
                            provide better solution for some IM. :-)
                            There is remaining problem that i should explain "CursorIM does not work
                            with SCIM and UIM" against many japanese IM users. j/k

                            Thanks.

                            --
                            - Yasuhiro Matsumoto

                            --~--~---------~--~----~------------~-------~--~----~
                            You received this message from the "vim_dev" maillist.
                            For more information, visit http://www.vim.org/maillist.php
                            -~----------~----~----~----~------~----~------~--~---
                          Your message has been successfully submitted and would be delivered to recipients shortly.