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

Re: bug in match function

Expand Messages
  • Bram Moolenaar
    ... Well, changing behavior when the {count} argument is given is a bit strange, but it s possible. This is a specific situation anyway, thus the user will
    Message 1 of 8 , Mar 2, 2006
      Marian Csontos wrote:

      > On Thu, 02 Mar 2006 16:04:16 +0100, Marian Csontos <csontos@...> wrote:
      >
      > > There should be possibility to get expected results:
      > > - additional parameter (kind of 'cpo' for one-time-use)
      >
      > I looked for message Bram mentioned, so there already is apropriate
      > parameter - 4th optional parameter - count.
      >
      > Now, what about changing behavior of function:
      > - if 4'th parameyer is not there - behave as in version 6.0
      > - othervise: behave as ``expected''
      > If someone wants behavior of 6.0 and to use 4th param too he could use
      > match(substr(str,pos),regexp,0,count).
      > May be a little complicated to explain in documentation.

      Well, changing behavior when the {count} argument is given is a bit
      strange, but it's possible. This is a specific situation anyway, thus
      the user will have to read the documentation about how it works.

      You would get a different behavior for {start} when providing a {count}
      of 1, without other side effects. It won't be possible to use a {count}
      of 2 and still have {start} work like in Vim 6.4, but that's probably
      not really a problem. You could use strpart() if you really need to.

      --
      The History of every major Galactic Civilization tends to pass through
      three distinct and recognizable phases, those of Survival, Inquiry and
      Sophistication, otherwise known as the How, Why and Where phases.
      For instance, the first phase is characterized by the question 'How can
      we eat?' the second by the question 'Why do we eat?' and the third by
      the question 'Where shall we have lunch?'
      -- Douglas Adams, "The Hitchhiker's Guide to the Galaxy"

      /// 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://www.ICCF.nl ///
    • Marian Csontos
      On Thu, 02 Mar 2006 19:56:57 +0100, Bram Moolenaar ... Thanks Bram, in documentation it is now corrected and explained really nice: For a
      Message 2 of 8 , Mar 3, 2006
        On Thu, 02 Mar 2006 19:56:57 +0100, Bram Moolenaar <Bram@...>
        wrote:

        >
        > Marian Csontos wrote:
        >
        >> On Thu, 02 Mar 2006 16:04:16 +0100, Marian Csontos <csontos@...>
        >> wrote:
        >>
        >> > There should be possibility to get expected results:
        >> > - additional parameter (kind of 'cpo' for one-time-use)
        >>
        >> I looked for message Bram mentioned, so there already is apropriate
        >> parameter - 4th optional parameter - count.
        >>
        >> Now, what about changing behavior of function:
        >> - if 4'th parameyer is not there - behave as in version 6.0
        >> - othervise: behave as ``expected''
        >> If someone wants behavior of 6.0 and to use 4th param too he could use
        >> match(substr(str,pos),regexp,0,count).
        >> May be a little complicated to explain in documentation.
        >
        > Well, changing behavior when the {count} argument is given is a bit
        > strange, but it's possible. This is a specific situation anyway, thus
        > the user will have to read the documentation about how it works.
        >
        > You would get a different behavior for {start} when providing a {count}
        > of 1, without other side effects. It won't be possible to use a {count}
        > of 2 and still have {start} work like in Vim 6.4, but that's probably
        > not really a problem. You could use strpart() if you really need to.
        >

        Thanks Bram,

        in documentation it is now corrected and explained really nice:

        For a String, if {start} > 0 then it is like the string starts
        {start} bytes later, thus "^" will match at {start}. Except
        when {count} is given, then it's like matches before the
        {start} byte are ignored (this is a bit complicated to keep it
        backwards compatible).

        but program still behaves as in version 6.x.

        I have 2 suggestions:
        1st: {count} starts from 1, not from 0 as I expected (I'm used to C++) - I
        think this could be mentioned in the documentation,
        2nd: to allow 6.x behavior also in 7.0, {count}'s default could be 0
        instead of 1, so if it's 0 -

        Regards,

        -- Marian


        ________ Information from NOD32 ________
        This message was checked by NOD32 Antivirus System for Linux Mail Server.
        part000.txt - is OK
        http://www.nod32.com
      • Marian Csontos
        On Thu, 02 Mar 2006 19:56:57 +0100, Bram Moolenaar wrote: sorry, previos mail got sent by mistake earlier than intended, here is
        Message 3 of 8 , Mar 3, 2006
          On Thu, 02 Mar 2006 19:56:57 +0100, Bram Moolenaar <Bram@...>
          wrote:

          sorry, previos mail got sent by mistake earlier than intended, here is
          continuation:

          suggestion for changing match*() doc and behavior:

          1st: {count} starts from 1, not from 0 as I expected (I'm used to C++) - I
          think this could be mentioned in the documentation,

          2nd: and as 0 is unnused so {count}'s default could be 0 instead of 1, so
          if it's 0 - it could behave as in 6.x and if it's > 0 - it could have
          other bahavior. So it is not dependent on number of arguments.

          Regards,

          -- Marian


          ________ Information from NOD32 ________
          This message was checked by NOD32 Antivirus System for Linux Mail Server.
          part000.txt - is OK
          http://www.nod32.com
        Your message has been successfully submitted and would be delivered to recipients shortly.