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

Patch 7.1.306

Expand Messages
  • Bram Moolenaar
    Patch 7.1.306 Problem: Some Unicode characters are handled like word characters while they are symbols. Solution: Adjust the table for Unicode
    Message 1 of 5 , Jun 4, 2008
    • 0 Attachment
      Patch 7.1.306
      Problem: Some Unicode characters are handled like word characters while
      they are symbols.
      Solution: Adjust the table for Unicode classification.
      Files: src/mbyte.c


      *** ../vim-7.1.305/src/mbyte.c Wed Feb 20 11:27:59 2008
      --- src/mbyte.c Wed May 21 20:49:34 2008
      ***************
      *** 1973,1980 ****
      {0x205f, 0x205f, 0},
      {0x2060, 0x27ff, 1}, /* punctuation and symbols */
      {0x2070, 0x207f, 0x2070}, /* superscript */
      ! {0x2080, 0x208f, 0x2080}, /* subscript */
      ! {0x2983, 0x2998, 1},
      {0x29d8, 0x29db, 1},
      {0x29fc, 0x29fd, 1},
      {0x3000, 0x3000, 0}, /* ideographic space */
      --- 1973,1982 ----
      {0x205f, 0x205f, 0},
      {0x2060, 0x27ff, 1}, /* punctuation and symbols */
      {0x2070, 0x207f, 0x2070}, /* superscript */
      ! {0x2080, 0x2094, 0x2080}, /* subscript */
      ! {0x20a0, 0x27ff, 1}, /* all kinds of symbols */
      ! {0x2800, 0x28ff, 0x2800}, /* braille */
      ! {0x2900, 0x2998, 1}, /* arrows, brackets, etc. */
      {0x29d8, 0x29db, 1},
      {0x29fc, 0x29fd, 1},
      {0x3000, 0x3000, 0}, /* ideographic space */
      *** ../vim-7.1.305/src/version.c Thu May 29 22:41:19 2008
      --- src/version.c Wed Jun 4 10:54:36 2008
      ***************
      *** 668,669 ****
      --- 673,676 ----
      { /* Add new patch number below this line */
      + /**/
      + 306,
      /**/

      --
      Engineers are always delighted to share wisdom, even in areas in which they
      have no experience whatsoever. Their logic provides them with inherent
      insight into any field of expertise. This can be a problem when dealing with
      the illogical people who believe that knowledge can only be derived through
      experience.
      (Scott Adams - The Dilbert principle)

      /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
      /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
      \\\ download, build and distribute -- http://www.A-A-P.org ///
      \\\ help me help AIDS victims -- http://ICCF-Holland.org ///

      --~--~---------~--~----~------------~-------~--~----~
      You received this message from the "vim_dev" maillist.
      For more information, visit http://www.vim.org/maillist.php
      -~----------~----~----~----~------~----~------~--~---
    • Tony Mechelynck
      ... After applying patches 7.1.306 to 7.1.308 (of which I haven t yet received the latter two by email) if_python.c: In function ‘VimToPython’:
      Message 2 of 5 , Jun 4, 2008
      • 0 Attachment
        On 04/06/08 10:59, Bram Moolenaar wrote:
        >
        > Patch 7.1.306
        > Problem: Some Unicode characters are handled like word characters while
        > they are symbols.
        > Solution: Adjust the table for Unicode classification.
        > Files: src/mbyte.c

        After applying patches 7.1.306 to 7.1.308 (of which I haven't yet
        received the latter two by email)

        if_python.c: In function ‘VimToPython’:
        if_python.c:1157: warning: format ‘%f’ expects type ‘double’, but
        argument 3 has type ‘long int’

        also, one of 37 hunks of 7.1.307 failed to patch in the "floating point"
        version but on eyeball inspection it was already included, though with
        an additional comment in the middle (hunk #10 at 1130, bracketed between
        #ifdef FEAT_FLOAT and #endif). Bram, don't you think that floating point
        feature could now be made a part of the "standard" sources? Of course,
        if anyone gets cold feet, it can still be disabled at compile-time by
        commenting away line 384 of feature.h (to /* #define FEAT_FLOAT */ or
        similar)


        Best regards,
        Tony.
        --
        ... so long as the people do not care to exercise their freedom, those
        who wish to tyrranize will do so; for tyrants are active and ardent,
        and will devote themselves in the name of any number of gods, religious
        and otherwise, to put shackles upon sleeping men.
        -- Voltarine de Cleyre

        --~--~---------~--~----~------------~-------~--~----~
        You received this message from the "vim_dev" maillist.
        For more information, visit http://www.vim.org/maillist.php
        -~----------~----~----~----~------~----~------~--~---
      • Bram Moolenaar
        ... Are you sure you patched OK? I see: sprintf(buf, %f , our_tv- vval.v_float); That is clearly a double argument. ... The FEAT_FLOAT parts in if_python
        Message 3 of 5 , Jun 4, 2008
        • 0 Attachment
          Tony Mechelynck wrote:

          > On 04/06/08 10:59, Bram Moolenaar wrote:
          > >
          > > Patch 7.1.306
          > > Problem: Some Unicode characters are handled like word characters while
          > > they are symbols.
          > > Solution: Adjust the table for Unicode classification.
          > > Files: src/mbyte.c
          >
          > After applying patches 7.1.306 to 7.1.308 (of which I haven't yet
          > received the latter two by email)
          >
          > if_python.c: In function 'VimToPython':
          > if_python.c:1157: warning: format '%f' expects type 'double', but
          > argument 3 has type 'long int'

          Are you sure you patched OK? I see:

          sprintf(buf, "%f", our_tv->vval.v_float);

          That is clearly a double argument.

          > also, one of 37 hunks of 7.1.307 failed to patch in the "floating point"
          > version but on eyeball inspection it was already included, though with
          > an additional comment in the middle (hunk #10 at 1130, bracketed between
          > #ifdef FEAT_FLOAT and #endif). Bram, don't you think that floating point
          > feature could now be made a part of the "standard" sources? Of course,
          > if anyone gets cold feet, it can still be disabled at compile-time by
          > commenting away line 384 of feature.h (to /* #define FEAT_FLOAT */ or
          > similar)

          The FEAT_FLOAT parts in if_python shouldn't hurt, since FEAT_FLOAT isn't
          yet defined anywhere. Unless you are using the experimental floating
          point patch, but then it should work (if you avoid patching the same
          thing twice).

          I still have a few fixes in the pipeline for the floating point patch.

          --
          Imagine a world without hypothetical situations.

          /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
          /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
          \\\ download, build and distribute -- http://www.A-A-P.org ///
          \\\ help me help AIDS victims -- http://ICCF-Holland.org ///

          --~--~---------~--~----~------------~-------~--~----~
          You received this message from the "vim_dev" maillist.
          For more information, visit http://www.vim.org/maillist.php
          -~----------~----~----~----~------~----~------~--~---
        • Tony Mechelynck
          ... sprintf(buf, %f , (long)our_tv- vval.v_float); That s part of that hulk which didn t apply, see below. I ll remove the typecast by hand. Here s the exact
          Message 4 of 5 , Jun 4, 2008
          • 0 Attachment
            On 04/06/08 17:24, Bram Moolenaar wrote:
            > Tony Mechelynck wrote:
            >
            >> On 04/06/08 10:59, Bram Moolenaar wrote:
            >>> Patch 7.1.306
            >>> Problem: Some Unicode characters are handled like word characters while
            >>> they are symbols.
            >>> Solution: Adjust the table for Unicode classification.
            >>> Files: src/mbyte.c
            >> After applying patches 7.1.306 to 7.1.308 (of which I haven't yet
            >> received the latter two by email)
            >>
            >> if_python.c: In function ‘VimToPython’:
            >> if_python.c:1157: warning: format ‘%f’ expects type ‘double’, but
            >> argument 3 has type ‘long int’
            >
            > Are you sure you patched OK? I see:
            >
            > sprintf(buf, "%f", our_tv->vval.v_float);

            sprintf(buf, "%f", (long)our_tv->vval.v_float);

            That's part of that hulk which didn't apply, see below. I'll remove the
            typecast by hand.

            Here's the exact text I have there, from #ifdef to #endif plus three
            lines of context either side, before removing that typecast:

            result = Py_BuildValue("s", buf);
            PyDict_SetItemString(lookupDict, ptrBuf, result);
            }
            #ifdef FEAT_FLOAT
            else if (our_tv->v_type == VAR_FLOAT)
            {
            char buf[NUMBUFLEN];

            /* For backwards compatibility numbers are stored as strings. */
            sprintf(buf, "%f", (long)our_tv->vval.v_float);
            result = Py_BuildValue("s", buf);
            PyDict_SetItemString(lookupDict, ptrBuf, result);
            }
            #endif
            else if (our_tv->v_type == VAR_LIST)
            {
            list_T *list = our_tv->vval.v_list;


            >
            > That is clearly a double argument.
            >
            >> also, one of 37 hunks of 7.1.307 failed to patch in the "floating point"
            >> version but on eyeball inspection it was already included, though with
            >> an additional comment in the middle (hunk #10 at 1130, bracketed between
            >> #ifdef FEAT_FLOAT and #endif). Bram, don't you think that floating point
            >> feature could now be made a part of the "standard" sources? Of course,
            >> if anyone gets cold feet, it can still be disabled at compile-time by
            >> commenting away line 384 of feature.h (to /* #define FEAT_FLOAT */ or
            >> similar)
            >
            > The FEAT_FLOAT parts in if_python shouldn't hurt, since FEAT_FLOAT isn't
            > yet defined anywhere. Unless you are using the experimental floating
            > point patch, but then it should work (if you avoid patching the same
            > thing twice).

            I am, and the patch program didn't reapply that hulk. I didn't check the
            other hulks (the ones which succeeded, sometimes with fuzz); I hope
            they're OK -- normally your diffs should have enough context for that. I
            still have (in a parallel directory structure) the version without the
            float patch but that's not the one I "install".

            >
            > I still have a few fixes in the pipeline for the floating point patch.
            >

            Aha! I can hardly wait.


            Best regards,
            Tony.
            --
            BLACK KNIGHT: None shall pass.
            ARTHUR: I have no quarrel with you, brave Sir knight, but I must cross
            this bridge.
            BLACK KNIGHT: Then you shall die.
            "Monty Python and the Holy Grail" PYTHON (MONTY)
            PICTURES LTD

            --~--~---------~--~----~------------~-------~--~----~
            You received this message from the "vim_dev" maillist.
            For more information, visit http://www.vim.org/maillist.php
            -~----------~----~----~----~------~----~------~--~---
          • Bill McCarthy
            ... I also found 307-311 on the ftp site. After deleting from the patches those portions applicable to runtime files (such as optwin.vim), they built fine. I
            Message 5 of 5 , Jun 4, 2008
            • 0 Attachment
              On Wed 4-Jun-08 3:59am -0600, Bram Moolenaar wrote:

              > Patch 7.1.306

              I also found 307-311 on the ftp site. After deleting from
              the patches those portions applicable to runtime files (such
              as optwin.vim), they built fine.

              I then turned to floating point (which I last updated at
              305). Only if_python.c and version.c needed to be updated
              (or so I thought).

              After the patch to if_python.c failed completely, version.c
              patched fine.

              On further inspection I see that the standard if_python.c is
              already patched for floating point. So I just copied it and
              my floating point versions of vim and gvim are at 311.

              Since eval.c didn't change, I didn't need to apply John
              Beckett's fp patch - will that be included?

              I didn't have any of Tony's problems. I agree that it would
              be great to have fp in the main distribution.

              --
              Best regards,
              Bill


              --~--~---------~--~----~------------~-------~--~----~
              You received this message from the "vim_dev" maillist.
              For more information, visit http://www.vim.org/maillist.php
              -~----------~----~----~----~------~----~------~--~---
            Your message has been successfully submitted and would be delivered to recipients shortly.