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

Re: clear_next don't work correctly.

Expand Messages
  • 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 1 of 10 , Apr 23, 2002
    • 0 Attachment
      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 2 of 10 , Apr 23, 2002
      • 0 Attachment
        > > >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.