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

[vim-multibyte] Mistake for CSI if 0x9B is contained in the multi-byte

Expand Messages
  • Yasuhiro Matsumoto
    Hi , Bram This is about console version. Vim is mistaken for CSI if 0x9B is contained in the multi-byte character. At this time, until a time-out is done, Vim
    Message 1 of 3 , Feb 21, 2000
    • 0 Attachment
      Hi , Bram

      This is about console version.

      Vim is mistaken for CSI if 0x9B is contained in the multi-byte character.
      At this time, until a time-out is done, Vim stands by.

      So, I made a patch.
      This was made from the source version 5.6.12.

      -------------------------------------------------
      Problem: Vim have mistake for CSI if 0x9B is contained in the multi-byte character.
      Solution: Don't wait if 0x9B is contained in the multi-byte character.
      Files: getchar.c

      *** src.orig/getchar.c Mon Jan 17 01:42:02 2000
      --- src/getchar.c Tue Feb 22 14:50:08 2000
      ***************
      *** 1452,1457 ****
      --- 1452,1469 ----
      {
      keylen = check_termcode(max_mlen + 1, NULL, 0);

      + #ifdef MULTI_BYTE
      + /*
      + * When having a CSI in multi-byte characters,
      + * don't wait for a typed character.
      + */
      + if (is_dbcs && typelen > 0)
      + {
      + char_u lbyte = *(typebuf + typeoff-1); /* leadbyte */
      + char_u tbyte = *(typebuf + typeoff ); /* trailbyte */
      + if (IsLeadByte(lbyte) && tbyte == CSI) keylen = 0;
      + }
      + #endif
      /*
      * When getting a partial match, but the last
      * characters were not typed, don't wait for a
    • Bram Moolenaar
      ... It looks good. I added another check if keylen
      Message 2 of 3 , Feb 22, 2000
      • 0 Attachment
        Yasuhiro Matsumoto wrote:

        > This is about console version.
        >
        > Vim is mistaken for CSI if 0x9B is contained in the multi-byte character.
        > At this time, until a time-out is done, Vim stands by.
        >
        > So, I made a patch.
        > This was made from the source version 5.6.12.

        It looks good. I added another check if "keylen < 0", so that a matched
        termcode isn't accidentally removed (although that's unlikely to happen
        anyway, just to be sure). Below is my alternative patch.

        Perhaps there should also be a check if "typeoff > 0"? Hmm, it seems
        "typelen > 0" isn't needed, it is already checked around line 1304. That
        should probably be "typeoff > 0" then. Please check!

        *** ../../vim-5.6/src/getchar.c Sun Jan 16 22:41:09 2000
        --- getchar.c Tue Feb 22 10:22:03 2000
        ***************
        *** 1452,1457 ****
        --- 1452,1469 ----
        {
        keylen = check_termcode(max_mlen + 1, NULL, 0);

        + #ifdef MULTI_BYTE
        + /*
        + * When a CSI appears in a multi-byte character,
        + * don't wait for another character.
        + */
        + if (keylen < 0 && is_dbcs && typeoff > 0)
        + {
        + if (IsLeadByte(*(typebuf + typeoff - 1))
        + && *(typebuf + typeoff) == CSI)
        + keylen = 0;
        + }
        + #endif
        /*
        * When getting a partial match, but the last
        * characters were not typed, don't wait for a

        --
        hundred-and-one symptoms of being an internet addict:
        72. Somebody at IRC just mentioned a way to obtain full motion video without
        a PC using a wireless protocol called NTSC, you wonder how you never
        heard about it

        /-/-- Bram Moolenaar --- Bram@... --- http://www.moolenaar.net --\-\
        \ \ Vim: http://www.vim.org ICCF Holland: http://www.vim.org/iccf / /
      • Yasuhiro Matsumoto
        ... I checked and tested it just now. Though it tried how many multi-byte to input, a problem doesn t seem that be at all. Thanks. Does 0x9B never come from
        Message 3 of 3 , Feb 22, 2000
        • 0 Attachment
          Bram Moolenaar wrote:
          > It looks good. I added another check if "keylen < 0", so that a matched
          > termcode isn't accidentally removed (although that's unlikely to happen
          > anyway, just to be sure). Below is my alternative patch.
          > Perhaps there should also be a check if "typeoff > 0"? Hmm, it seems
          > "typelen > 0" isn't needed, it is already checked around line 1304. That
          > should probably be "typeoff > 0" then. Please check!

          I checked and tested it just now.
          Though it tried how many multi-byte to input,
          a problem doesn't seem that be at all.
          Thanks.

          Does 0x9B never come from the first byte?
          This patch is OK if it can't be here.
        Your message has been successfully submitted and would be delivered to recipients shortly.