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

Re: clear_next don't work correctly.

Expand Messages
  • Yasuhiro Matsumoto
    ... Hmm..., this is problem of this logic. mb_off2cells should work correctly if the string is not broken. but clear_next_cell might break the combination for
    Message 1 of 10 , Apr 22, 2002
      >Well, I can predict that if we fix it this way, the problem with
      >mb_off2cell() will pop up later anyway. Since the utf-8 version of this
      >function returns 1 when used on the right halve of a double-wide
      >character, I think the dbcs version should do the same.
      >
      >I know this is a bit of work to get right, but I think it's worth it.

      Hmm..., this is problem of this logic.

      mb_off2cells should work correctly if the string is not broken.
      but clear_next_cell might break the combination for leadbyte and trailbyte
      until the part write a space.
      Thus, mb_off2cells don't return right value.
      It should not use same logic for filling a space.
      And it should overwrite a space by force before breaking leadbyte.

      I made a patch for this problem.
      and I tested few case as following.

      cp932 & cpoptions+=$ : cw
      euc-jp & cpoptions+=$ : cw
      utf-8 & cpoptions+=$ : cw

      It seems good to me.

      Thanks.

      ------------------------------------
      *** screen.c.org Tue Apr 23 11:13:36 2002
      --- screen.c Tue Apr 23 11:13:41 2002
      ***************
      *** 5177,5183 ****
      /* When at the end of the text and overwriting a two-cell
      * character with a one-cell character, need to clear the next
      * cell. Also when overwriting the left halve of a two-cell
      ! * char with the right halve of a two-cell char. */
      if (has_mbyte && ptr[mbyte_blen] == NUL
      && ((mbyte_cells == 1 && (*mb_off2cells)(off) > 1)
      || (mbyte_cells == 2
      --- 5177,5185 ----
      /* When at the end of the text and overwriting a two-cell
      * character with a one-cell character, need to clear the next
      * cell. Also when overwriting the left halve of a two-cell
      ! * char with the right halve of a two-cell char.
      ! * See under ...
      ! */
      if (has_mbyte && ptr[mbyte_blen] == NUL
      && ((mbyte_cells == 1 && (*mb_off2cells)(off) > 1)
      || (mbyte_cells == 2
      ***************
      *** 5219,5224 ****
      --- 5221,5235 ----
      else
      #endif
      screen_char(off, row, col);
      +
      + #ifdef FEAT_MBYTE
      + /* Need to erase the cell */
      + if (clear_next_cell)
      + {
      + ScreenLines[off + mbyte_cells] = ' ';
      + screen_char(off + mbyte_cells, row, col + mbyte_cells);
      + }
      + #endif
      }
      #ifdef FEAT_MBYTE
      if (has_mbyte)
      ***************
      *** 5226,5236 ****
      off += mbyte_cells;
      col += mbyte_cells;
      ptr += mbyte_blen;
      - if (clear_next_cell)
      - {
      - ptr = (char_u *)" ";
      - clear_next_cell = FALSE;
      - }
      }
      else
      #endif
      --- 5237,5242 ----
      --
      Yasuhiro



      _________________________________________________________________
      MSN Photos is the easiest way to share and print your photos:
      http://photos.msn.com/support/worldwide.aspx
    • Bram Moolenaar
      ... Yeah, that makes it complicated. The utf-8 character is stored separately, which means this is still available even when the left halve of the wide
      Message 2 of 10 , Apr 23, 2002
        Yasuhiro Matsumoto wrote:

        > >Well, I can predict that if we fix it this way, the problem with
        > >mb_off2cell() will pop up later anyway. Since the utf-8 version of this
        > >function returns 1 when used on the right halve of a double-wide
        > >character, I think the dbcs version should do the same.
        > >
        > >I know this is a bit of work to get right, but I think it's worth it.
        >
        > Hmm..., this is problem of this logic.
        >
        > mb_off2cells should work correctly if the string is not broken.
        > but clear_next_cell might break the combination for leadbyte and trailbyte
        > until the part write a space.

        Yeah, that makes it complicated. The utf-8 character is stored
        separately, which means this is still available even when the left halve
        of the wide character was overwritten. For dbcs the lead byte has been
        overwritten, thus we no longer have the info about the second byte
        actually being a tail byte in the past.

        > Thus, mb_off2cells don't return right value.
        > It should not use same logic for filling a space.
        > And it should overwrite a space by force before breaking leadbyte.
        >
        > I made a patch for this problem.
        > and I tested few case as following.
        >
        > cp932 & cpoptions+=$ : cw
        > euc-jp & cpoptions+=$ : cw
        > utf-8 & cpoptions+=$ : cw
        >
        > It seems good to me.

        Didn't we have it like this in the past? I'll have to check if there is
        no situation where this solution causes a problem. There was a reason
        we use clear_next_cell and don't write the space right there. Your
        patch looks good though.

        --
        GALAHAD hurries to the door and pushes through it. As he leaves the room
        we CUT TO the reverse to show that he is now in a room full of bathing
        and romping GIRLIES, all innocent, wide-eyed and beautiful. They smile
        enchantingly at him as he tries to keep walking without being diverted by
        the lovely sights assaulting his eyeballs.
        "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

        /// Bram Moolenaar -- Bram@... -- http://www.moolenaar.net \\\
        /// Creator of Vim -- http://vim.sf.net -- ftp://ftp.vim.org/pub/vim \\\
        \\\ Project leader for A-A-P -- http://www.a-a-p.org ///
        \\\ Help me helping AIDS orphans in Uganda - http://iccf-holland.org ///
      • Yasuhiro Matsumoto
        ... It happened some time with few specified dbcs character. The character have possible to be made by trailbyte and leadbyte. I m testing before sent the last
        Message 3 of 10 , Apr 23, 2002
          > > >Well, I can predict that if we fix it this way, the problem with
          > > >mb_off2cell() will pop up later anyway. Since the utf-8 version of
          >this
          > > >function returns 1 when used on the right halve of a double-wide
          > > >character, I think the dbcs version should do the same.
          > > >
          > > >I know this is a bit of work to get right, but I think it's worth it.
          > >
          > > Hmm..., this is problem of this logic.
          > >
          > > mb_off2cells should work correctly if the string is not broken.
          > > but clear_next_cell might break the combination for leadbyte and
          >trailbyte
          > > until the part write a space.
          >
          >Yeah, that makes it complicated. The utf-8 character is stored
          >separately, which means this is still available even when the left halve
          >of the wide character was overwritten. For dbcs the lead byte has been
          >overwritten, thus we no longer have the info about the second byte
          >actually being a tail byte in the past.
          >
          > > Thus, mb_off2cells don't return right value.
          > > It should not use same logic for filling a space.
          > > And it should overwrite a space by force before breaking leadbyte.
          > >
          > > I made a patch for this problem.
          > > and I tested few case as following.
          > >
          > > cp932 & cpoptions+=$ : cw
          > > euc-jp & cpoptions+=$ : cw
          > > utf-8 & cpoptions+=$ : cw
          > >
          > > It seems good to me.
          >
          >Didn't we have it like this in the past? I'll have to check if there is
          >no situation where this solution causes a problem. There was a reason
          >we use clear_next_cell and don't write the space right there. Your
          >patch looks good though.

          It happened some time with few specified dbcs character.
          The character have possible to be made by trailbyte and leadbyte.

          I'm testing before sent the last mail.
          But I don't see the problem.

          Thanks.

          *** screen.c.orig.002 Tue Apr 23 05:06:21 2002
          --- screen.c Tue Apr 23 18:27:24 2002
          ***************
          *** 5177,5183 ****
          /* When at the end of the text and overwriting a two-cell
          * character with a one-cell character, need to clear the next
          * cell. Also when overwriting the left halve of a two-cell
          ! * char with the right halve of a two-cell char. */
          if (has_mbyte && ptr[mbyte_blen] == NUL
          && ((mbyte_cells == 1 && (*mb_off2cells)(off) > 1)
          || (mbyte_cells == 2
          --- 5177,5185 ----
          /* When at the end of the text and overwriting a two-cell
          * character with a one-cell character, need to clear the next
          * cell. Also when overwriting the left halve of a two-cell
          ! * char with the right halve of a two-cell char.
          ! * See under ...
          ! */
          if (has_mbyte && ptr[mbyte_blen] == NUL
          && ((mbyte_cells == 1 && (*mb_off2cells)(off) > 1)
          || (mbyte_cells == 2
          ***************
          *** 5219,5224 ****
          --- 5221,5239 ----
          else
          #endif
          screen_char(off, row, col);
          +
          + #ifdef FEAT_MBYTE
          + /* Need to erase the cell */
          + if (clear_next_cell)
          + {
          + if (enc_utf8)
          + ScreenLinesUC[off + mbyte_cells] = 0;
          + else if (enc_dbcs == DBCS_JPNU)
          + ScreenLines2[off + mbyte_cells] = ' ';
          + ScreenLines[off + mbyte_cells] = ' ';
          + screen_char(off + mbyte_cells, row, col + mbyte_cells);
          + }
          + #endif
          }
          #ifdef FEAT_MBYTE
          if (has_mbyte)
          ***************
          *** 5226,5236 ****
          off += mbyte_cells;
          col += mbyte_cells;
          ptr += mbyte_blen;
          - if (clear_next_cell)
          - {
          - ptr = (char_u *)" ";
          - clear_next_cell = FALSE;
          - }
          }
          else
          #endif
          --- 5241,5246 ----



          _________________________________________________________________
          Send and receive Hotmail on your mobile device: http://mobile.msn.com
        Your message has been successfully submitted and would be delivered to recipients shortly.