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

Re: clear_next don't work correctly.

Expand Messages
  • Bram Moolenaar
    ... That s not what I was asking. Where you say mbyte_cells become 2 , I don t understand it. mbyte_cells is 1 when displaying the extra . Do you mean
    Message 1 of 10 , Apr 20, 2002
    • 0 Attachment
      Yasuhiro Matsumoto wrote:

      > >I don't see how this can go wrong, unless the mb_off2cells() call gives
      > >a wrong result. I guess that might happen when it's called with an
      > >offset that points to the right halve of a double-wide character. At
      > >least for DBCS characters this does not appear to be checked and an
      > >invalid result might be returned.
      > >
      > >I think we should attempt to fix the cause of the problem and not work
      > >around it. mb_off2cells() appears to be used in several places where we
      > >don't know if we are looking at a single-byte character, the head byte
      > >or the tail byte of a double-byte character. Can this be fixed?
      >
      > Hmm, I guess that the patch should be included.
      > if leadbyte erase by single-width character,
      > double-width character will be broken.
      > Then, the trailbyte and leadbyte of next character might become DBCS.
      >
      > For example, putting ' ' on '[][]'.
      >
      > [][] : clear_next_cell will be TRUE
      > v
      > ][] : set ptr = " ", but mbyte_cells become 2.
      > v
      > [] : thus, set ptr = " " again.
      > v
      > ] : repeat ....
      > v
      > : repeat ....

      That's not what I was asking. Where you say "mbyte_cells become 2", I
      don't understand it. mbyte_cells is 1 when displaying the extra " ".
      Do you mean mb_off2cells() returns 2? That is the problem I was talking
      about.

      --
      Emacs is a nice OS - but it lacks a good text editor.
      That's why I am using Vim. --Anonymous

      /// 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
      ... And your said is true. I m explaining again, sorry. For example, putting on [][] . [][] : mbyte_cell=2, (*mb_off2cell)(off)=2,
      Message 2 of 10 , Apr 21, 2002
      • 0 Attachment
        >That's not what I was asking. Where you say "mbyte_cells become 2", I
        >don't understand it. mbyte_cells is 1 when displaying the extra " ".
        >Do you mean mb_off2cells() returns 2? That is the problem I was talking
        >about.

        And your said is true.
        I'm explaining again, sorry.

        For example, putting ' ' on '[][]'.

        [][] : mbyte_cell=2, (*mb_off2cell)(off)=2, (*mb_off2cell)(off+1)=2,
        thus clear_next_cell become TRUE.
        ... ptr will be set " ".
        v
        ][] : mbyte_cells=1, (*mb_off2cell)(off)=2
        thus clear_next_cell become TRUE.
        ... ptr will be set " ".
        v
        [] : repeat ....
        v
        ] : repeat ....

        We can't judge the character is whether it is a leadbyte or trailbyte
        correctly.
        Thus what we can do is to stop the repeat.

        I guess that the patch should be included.

        Thanks.
        --
        Yasuhiro



        _________________________________________________________________
        Chat with friends online, try MSN Messenger: http://messenger.msn.com
      • Yasuhiro Matsumoto
        ... I had sent the e-mail included typo. ... This is my fault. And your said is true. ... .......... Thanks. -- Yasuhiro
        Message 3 of 10 , Apr 21, 2002
        • 0 Attachment
          >That's not what I was asking. Where you say "mbyte_cells become 2", I
          >don't understand it. mbyte_cells is 1 when displaying the extra " ".
          >Do you mean mb_off2cells() returns 2? That is the problem I was talking
          >about.

          I had sent the e-mail included typo.

          ---------------------------
          This is my fault.
          And your said is true.
          ---------------------------
          ..........

          Thanks.
          --
          Yasuhiro



          _________________________________________________________________
          Join the world�s largest e-mail service with MSN Hotmail.
          http://www.hotmail.com
        • Bram Moolenaar
          ... 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
          Message 4 of 10 , Apr 22, 2002
          • 0 Attachment
            Yasuhiro Matsumoto wrote:

            > >That's not what I was asking. Where you say "mbyte_cells become 2", I
            > >don't understand it. mbyte_cells is 1 when displaying the extra " ".
            > >Do you mean mb_off2cells() returns 2? That is the problem I was talking
            > >about.
            >
            > And your said is true.
            > I'm explaining again, sorry.
            >
            > For example, putting ' ' on '[][]'.
            >
            > [][] : mbyte_cell=2, (*mb_off2cell)(off)=2, (*mb_off2cell)(off+1)=2,
            > thus clear_next_cell become TRUE.
            > ... ptr will be set " ".
            > v
            > ][] : mbyte_cells=1, (*mb_off2cell)(off)=2
            > thus clear_next_cell become TRUE.
            > ... ptr will be set " ".
            > v
            > [] : repeat ....
            > v
            > ] : repeat ....
            >
            > We can't judge the character is whether it is a leadbyte or trailbyte
            > correctly.
            > Thus what we can do is to stop the repeat.
            >
            > I guess that the patch should be included.

            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.

            --
            Error:015 - Unable to exit Windows. Try the door.

            /// 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
            ... 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 5 of 10 , Apr 22, 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.
              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 6 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 7 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.