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

Re: Vim60v XIM problems

Expand Messages
  • Bram Moolenaar
    ... I have included the changes to escape a CSI. Perhaps there is some other character that needs to be escaped, or there is still a CSI that isn t escaped
    Message 1 of 3 , Feb 15, 2001
    • 0 Attachment
      Takuhiro Nishioka wrote:

      > I've noticed 2 XIM problems on Vim60v. Just report, not investigated
      > enough.
      >
      > Environment:
      >
      > OS: FreeBSD 4.2-STABLE
      > iconv: libiconv 1.5.1
      > Vim: GTK GUI version Vim 6.0v
      > Vim Settings:
      >
      > set encoding=UTF-8
      > set fileencodings=ISO-2022-JP,US-ASCII,EUC-JP,Shift_JIS
      > set termencoding=EUC-JP
      > set guifont=-misc-fixed-medium-r-normal--18-120-100-100-c-90-iso10646-1
      > set guifontwide=-misc-fixed-medium-r-normal-ja-18-120-100-100-c-180-iso10646-1
      >
      > 1. Inserting a Japanese character isn't handled correctly.
      >
      > This is similar problem, that I've reported before to
      > Bram. When I preedit one Japanese character, then to fix
      > preediting, pressing <Enter> key doesn't work. Hitting
      > <Enter> key 2 or 3 times, I could fix the preediting
      > process but an unknown character is inserted instead of
      > the Japanese character. And there happens some strange
      > behavior. After that, sometimes, inserting new characters
      > erases formaly inserted some characters.
      >
      > Inserting more than 1 Japanese character works good.

      I have included the changes to escape a CSI. Perhaps there is some other
      character that needs to be escaped, or there is still a CSI that isn't escaped
      yet? Please try to figure out what happens. Perhaps inserting a charcter
      that doesn't contain a CSI byte does work?

      > 2. Inserting 3 ascii characters via XIM doesn't work correctly.
      >
      > This is the same problem, that I've reported before to
      > Bram. But I'll post about this also to this mailing-list.
      > When I input just 3 ascii characters via XIM. Only the
      > first character is inserted, not 3 of characters. For
      > example:
      > abc
      > preediting "abc" character. Preediting process was
      > displayed correct. But when I fixed the preediting text
      > by hitting <Enter> key. Then only the first character
      > is inserted:
      > a
      > This happens just 3 ascii characters. 1, 2 and more
      > than 3 is OK.

      I think I have located this problem. Please try out this patch:


      *** gui_gtk_x11.c~ Tue Feb 13 15:01:54 2001
      --- gui_gtk_x11.c Thu Feb 15 20:16:30 2001
      ***************
      *** 735,741 ****
      string[0] = CSI;
      string[1] = special_keys[i].code0;
      string[2] = special_keys[i].code1;
      ! len = 3;
      break;
      }
      }
      --- 735,741 ----
      string[0] = CSI;
      string[1] = special_keys[i].code0;
      string[2] = special_keys[i].code1;
      ! len = -3;
      break;
      }
      }
      ***************
      *** 745,751 ****
      return TRUE;

      /* Special keys (and a few others) may have modifiers */
      ! if (len == 3 || key_sym == GDK_space || key_sym == GDK_Tab
      || key_sym == GDK_Return || key_sym == GDK_Linefeed
      || key_sym == GDK_Escape)
      {
      --- 745,751 ----
      return TRUE;

      /* Special keys (and a few others) may have modifiers */
      ! if (len == -3 || key_sym == GDK_space || key_sym == GDK_Tab
      || key_sym == GDK_Return || key_sym == GDK_Linefeed
      || key_sym == GDK_Escape)
      {
      ***************
      *** 760,766 ****
      /* It seems GDK returns GDK_VoidSymbol if the len is 3 and it
      * contains multi-byte characters. Is next is right?
      */
      ! if (!enc_dbcs || key_sym != GDK_VoidSymbol)
      #endif
      {
      /*
      --- 760,766 ----
      /* It seems GDK returns GDK_VoidSymbol if the len is 3 and it
      * contains multi-byte characters. Is next is right?
      */
      ! /* if (!enc_dbcs || key_sym != GDK_VoidSymbol) */
      #endif
      {
      /*
      ***************
      *** 768,774 ****
      * code. Do we need to handle the case where len != 1 and
      * string[0] != CSI?
      */
      ! if (string[0] == CSI && len == 3)
      key = TO_SPECIAL(string[1], string[2]);
      else
      key = string[0];
      --- 768,774 ----
      * code. Do we need to handle the case where len != 1 and
      * string[0] != CSI?
      */
      ! if (string[0] == CSI && len == -3)
      key = TO_SPECIAL(string[1], string[2]);
      else
      key = string[0];

      --
      ARTHUR: What?
      BLACK KNIGHT: None shall pass.
      ARTHUR: I have no quarrel with you, good Sir knight, but I must cross
      this bridge.
      BLACK KNIGHT: Then you shall die.
      The Quest for the Holy Grail (Monty Python)

      /// Bram Moolenaar -- Bram@... -- http://www.moolenaar.net \\\
      ((( Creator of Vim - http://www.vim.org -- ftp://ftp.vim.org/pub/vim )))
      \\\ Help me helping AIDS orphans in Uganda - http://iccf-holland.org ///
    • Takuhiro Nishioka
      Hello, ... [...] ... [...] ... This patch fixed the both of the problem. Now, I can input 1 Japanese character correctly, and I can input 3 ascii character
      Message 2 of 3 , Feb 15, 2001
      • 0 Attachment
        Hello,

        Bram Moolenaar wrote:
        > > 1. Inserting a Japanese character isn't handled correctly.
        [...]
        > I have included the changes to escape a CSI. Perhaps there is some other
        > character that needs to be escaped, or there is still a CSI that isn't escaped
        > yet? Please try to figure out what happens. Perhaps inserting a charcter
        > that doesn't contain a CSI byte does work?

        > > 2. Inserting 3 ascii characters via XIM doesn't work correctly.
        [...]
        > I think I have located this problem. Please try out this patch:

        This patch fixed the both of the problem. Now, I can
        input 1 Japanese character correctly, and I can input 3
        ascii character via XIM. Thanks!

        --
        Takuhiro Nishioka mailto:takuhiro@...
      Your message has been successfully submitted and would be delivered to recipients shortly.