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

[vim-multibyte] Re: multibyte patch

Expand Messages
  • Park Chong-Dae
    ... I think it does not work. Suppose this setting. XY AB Guess you are on the first X . When typing the t command, it moves to space first. Now type ==
    Message 1 of 11 , Mar 25, 2000
    • 0 Attachment
      On Fri, Mar 24, 2000 at 09:31:18PM +0100, Bram Moolenaar wrote:
      > This looks OK to me. But let's hear it from people actually using double-byte
      > characters.
      >
      > One simplification that appears to be possible:
      >
      > > if (type)
      > > + {
      > > col -= dir;
      > > +#ifdef MULTI_BYTE
      > > + if (is_dbcs && IsTrailByte(p, &p[col]))
      > > + col -= dir; /* skip multibyte's trail byte */
      > > +#endif
      > > + }
      >
      > I think this can be changed to:
      >
      > if (type)
      > {
      > /* backup to before the character (possibly double-byte) */
      > col -= dir;
      > #ifdef MULTI_BYTE
      > if (char_bytes == 2)
      > col -= dir;
      > #endif
      > }
      >
      > This avoids a IsTrailByte() call, which can be slow. But please check that
      > this is correct.

      I think it does not work.

      Suppose this setting.

      XY AB

      Guess you are on the first 'X'.
      When typing the 't ' command, it moves to space first.
      Now "type == TURE", it moves to opposite direction(in this case, backward).
      The cursor goes to Y position, where is the second byte of "XY".
      (But char_bytes == 1). This occurs in forward search only. In backward search
      case('T' cmannd cases: the opposite movement is now forward direction),
      your code would work faster. However this routine is called only once for each
      call. So I choose the simple case. I think the performance is not important
      here.

      For the performance, mb_byte1(), mb_byte2(), and IsTrailByte() should be
      avoided. In my patch submitted yesterday(screen.c patch for screen_line()),
      I can remove mb_isbyte1() call. I'll post the patch if the submitted one
      does not have any problem. (My new patch would be just a performance tuning.)

      --
      Chong-Dae Park
      --
      Han Solo: That's 'cause droids don't pull people's arms out of their sockets
      when they lose. Wookiees are known to do that.
      C-3PO: I see your point, sir. I suggest a new strategy, R2! let the Wookiee
      win.
      - from "Star Wars: A New Hope"
    • Bram Moolenaar
      ... Thanks for checking. ... Well, when using long lines this can be important anyway. And it s easy to make it like this: if (type) { /* backup to before the
      Message 2 of 11 , Mar 25, 2000
      • 0 Attachment
        Park Chong-Dae wrote:

        > > This avoids a IsTrailByte() call, which can be slow. But please check that
        > > this is correct.
        >
        > I think it does not work.

        Thanks for checking.

        > XY AB
        >
        > Guess you are on the first 'X'.
        > When typing the 't ' command, it moves to space first.
        > Now "type == TURE", it moves to opposite direction(in this case, backward).
        > The cursor goes to Y position, where is the second byte of "XY".
        > (But char_bytes == 1). This occurs in forward search only. In backward search
        > case('T' cmannd cases: the opposite movement is now forward direction),
        > your code would work faster. However this routine is called only once for each
        > call. So I choose the simple case. I think the performance is not important
        > here.

        Well, when using long lines this can be important anyway. And it's easy to
        make it like this:

        if (type)
        {
        /* backup to before the character (possibly double-byte) */
        col -= dir;
        #ifdef MULTI_BYTE
        if (is_dbcs
        && ((dir < 0 && char_bytes == 2)
        ||(dir > 0 && IsTrailByte(p, &p[col]))))
        col -= dir;
        #endif
        }

        Again, please check that this works correctly.

        > For the performance, mb_byte1(), mb_byte2(), and IsTrailByte() should be
        > avoided. In my patch submitted yesterday(screen.c patch for screen_line()),
        > I can remove mb_isbyte1() call. I'll post the patch if the submitted one
        > does not have any problem. (My new patch would be just a performance tuning.)

        Performance for screen_line() is very important. It's used for all display
        updating.

        --
        Microsoft's definition of a boolean: TRUE, FALSE, MAYBE
        "Embrace and extend"...?

        /-/-- Bram Moolenaar --- Bram@... --- http://www.moolenaar.net --\-\
        \-\-- Vim: http://www.vim.org ---- ICCF Holland: http://www.vim.org/iccf --/-/
      • Park Chong-Dae
        ... It seems work correctly. ... If performance is most important, how about to make IsLeadByte as a MACRO function? In WIN32 or BROKEN_LOCALE, It could be
        Message 3 of 11 , Mar 25, 2000
        • 0 Attachment
          On Sat, Mar 25, 2000 at 07:54:01PM +0100, Bram Moolenaar wrote:
          > Well, when using long lines this can be important anyway. And it's easy to
          > make it like this:
          >
          > if (type)
          > {
          > /* backup to before the character (possibly double-byte) */
          > col -= dir;
          > #ifdef MULTI_BYTE
          > if (is_dbcs
          > && ((dir < 0 && char_bytes == 2)
          > ||(dir > 0 && IsTrailByte(p, &p[col]))))
          > col -= dir;
          > #endif
          > }
          >
          > Again, please check that this works correctly.

          It seems work correctly.

          > > For the performance, mb_byte1(), mb_byte2(), and IsTrailByte() should be
          > > avoided. In my patch submitted yesterday(screen.c patch for screen_line()),
          > > I can remove mb_isbyte1() call. I'll post the patch if the submitted one
          > > does not have any problem. (My new patch would be just a performance tuning.)
          >
          > Performance for screen_line() is very important. It's used for all display
          > updating.

          If performance is most important, how about to make IsLeadByte as a MACRO
          function? In WIN32 or BROKEN_LOCALE, It could be substituted as a MACRO.
          And IsLeadByte is called most frequently in the MULTI_BYTE environment.

          PS: Is there a safe and efficient way to guess IsLeadByte
          without calling mblen()?


          --
          Chong-Dae Park
          --
          "I am a HAL 9000 computer, Production Number 3. I became operational
          at the HAL Plant in Urbana, Illinois on January 12, 1997."
          - spoken by HAL in the book 2001: A Space Odyssey, Arthur C. Clarke
        • Bram Moolenaar
          ... Would be possible. However, IsLeadByte() only takes one argument, and it does do a bit of work. Thus the overhead of the function call shouldn t be that
          Message 4 of 11 , Mar 26, 2000
          • 0 Attachment
            Park Chong-Dae wrote:

            > > Performance for screen_line() is very important. It's used for all display
            > > updating.
            >
            > If performance is most important, how about to make IsLeadByte as a MACRO
            > function? In WIN32 or BROKEN_LOCALE, It could be substituted as a MACRO.
            > And IsLeadByte is called most frequently in the MULTI_BYTE environment.

            Would be possible. However, IsLeadByte() only takes one argument, and it does
            do a bit of work. Thus the overhead of the function call shouldn't be that
            much. Just try to keep the number of calls to IsLeadByte() low.

            --
            FATHER: One day, lad, all this will be yours ...
            PRINCE: What - the curtains?
            "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

            /-/-- Bram Moolenaar --- Bram@... --- http://www.moolenaar.net --\-\
            \-\-- Vim: http://www.vim.org ---- ICCF Holland: http://www.vim.org/iccf --/-/
          Your message has been successfully submitted and would be delivered to recipients shortly.