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

Re: clear_next don't work correctly.

Expand Messages
  • Bram Moolenaar
    ... 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
    Message 1 of 10 , Apr 17, 2002
    • 0 Attachment
      Yasuhiro Matsumoto wrote:

      > clear_next_cell don't work correctly.
      > on some case, following text will be erased.
      > this happend with text included underline.
      >
      > old text:
      > [][][]
      >
      > new text:(override)
      > [][][]
      > |
      > v
      > []
      > ~~ <= underline
      >
      > following patch will be fix this.
      > this patch made by AIDA Shinra.

      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?

      --
      hundred-and-one symptoms of being an internet addict:
      220. Your wife asks for sex and you tell her where to find you on IRC.

      /// 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, 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
      Message 2 of 10 , Apr 18, 2002
      • 0 Attachment
        >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 ....

        Thanks.


        _________________________________________________________________
        Chat with friends online, try MSN Messenger: http://messenger.msn.com
      • 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 3 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 4 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 5 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 6 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 7 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 8 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 9 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.