bug in match function

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

bug in match function

Marian Csontos
Hi folks,

I was playing with tip for displaying matches highlighted  
(http://vim.sourceforge.net/tips/tip.php?tip_id=1141) and found out that:

match('abc def','\<',0) returns 0 - OK
match('abc def','\<',1) returns 1 instead of 4

similarly

match('abc def','^',0) returns 0 - OK
match('abc def','^',1) returns 1 instead of -1

Should be this considered a bug?

In both Vim 6.3.86 and 7.00aa snapshot 205

-- Regards

Marian

PS: dute to problem with mail server I've sent this 3rd time and hope  
first 2 attempts are definitively lost. Otherwise sorry for disturbing.


________ Information from NOD32 ________
This message was checked by NOD32 Antivirus System for Linux Mail Server.
  part000.txt - is OK
http://www.nod32.com
Reply | Threaded
Open this post in threaded view
|

Re: bug in match function

Bram Moolenaar

Marian Csontos wrote:

> I was playing with tip for displaying matches highlighted  
> (http://vim.sourceforge.net/tips/tip.php?tip_id=1141) and found out that:
>
> match('abc def','\<',0) returns 0 - OK
> match('abc def','\<',1) returns 1 instead of 4
>
> similarly
>
> match('abc def','^',0) returns 0 - OK
> match('abc def','^',1) returns 1 instead of -1
>
> Should be this considered a bug?
>
> In both Vim 6.3.86 and 7.00aa snapshot 205

A similar remark popped up recently.  When you give a start offset to
match() then it will consider that position the start of the string.
Thus "^" and "\<" will match there.

This may be unexpected, but changing it would have problems with
backwards compatibility.  Thus I've added a remark to the documentation.

--
In many of the more relaxed civilizations on the Outer Eastern Rim of the
Galaxy, "The Hitchhiker's Guide to the Galaxy" has already supplanted the
great "Encyclopedia Galactica" as the standard repository of all knowledge
and wisdom, for though it has many omissions and contains much that is
apocryphal, or at least wildly inaccurate, it scores over the older, more
pedestrian work in two important respects.
First, it is slightly cheaper; and second, it has the words "DON'T PANIC"
inscribed in large friendly letters on its cover.
                -- Douglas Adams, "The Hitchhiker's Guide to the Galaxy"

 /// Bram Moolenaar -- [hidden email] -- 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         ///
Reply | Threaded
Open this post in threaded view
|

Re: bug in match function

A.J.Mechelynck
In reply to this post by Marian Csontos
Marian Csontos wrote:

> Hi folks,
>
> I was playing with tip for displaying matches highlighted
> (http://vim.sourceforge.net/tips/tip.php?tip_id=1141) and found out that:
>
> match('abc def','\<',0) returns 0 - OK
> match('abc def','\<',1) returns 1 instead of 4
>
> similarly
>
> match('abc def','^',0) returns 0 - OK
> match('abc def','^',1) returns 1 instead of -1
>
> Should be this considered a bug?
>
> In both Vim 6.3.86 and 7.00aa snapshot 205
>
> -- Regards
>
> Marian

31 lines down from ":help match()" for 7.0aa snapshot 211:

        For a String, if {start} > 0 then it is like the string starts
        {start} bytes later, thus "^" will match there.


IOW, "it's not a bug, it's a feature". Whatever precedes the start
position is not even examined. '^' will always match at {start}; '\<'
will match there unless the ({start}+1)th character is not a word
character (I guess 'iskeyword' is the relevant criterion).


From what the help says, I would expect (untested)

    match(str, '^', i) == i for any integer i >= 0 and <= strlen(str)
and
    match('abc def', '\<', 0) == 0
    match('abc def', '\<', 1) == 1
    match('abc def', '\<', 2) == 2
    match('abc def', '\<', 3) == 4
    match('abc def', '\<', 4) == 4
    match('abc def', '\<', 5) == 5
    match('abc def', '\<', 6) == 6
    match('abc def', '\<', 7) == -1
etc.


Best regards,
Tony.

Reply | Threaded
Open this post in threaded view
|

Re: bug in match function

Marian Csontos
In reply to this post by Bram Moolenaar
On Thu, 02 Mar 2006 15:40:57 +0100, Bram Moolenaar <[hidden email]>  
wrote:

> Marian Csontos wrote:
>> I was playing with tip for displaying matches highlighted
>> (http://vim.sourceforge.net/tips/tip.php?tip_id=1141) and found out  
>> that:
>>
>> match('abc def','\<',0) returns 0 - OK
>> match('abc def','\<',1) returns 1 instead of 4
>>
>> similarly
>>
>> match('abc def','^',0) returns 0 - OK
>> match('abc def','^',1) returns 1 instead of -1
>>
>> Should be this considered a bug?
>>
>> In both Vim 6.3.86 and 7.00aa snapshot 205
>
> A similar remark popped up recently. When you give a start offset to
> match() then it will consider that position the start of the string.
> Thus "^" and "\<" will match there.
>
> This may be unexpected, but changing it would have problems with
> backwards compatibility.  Thus I've added a remark to the documentation.
>

It reminds me some of MS's practices: It's a bug, but compatible bug ;-)

There should be possibility to get expected results:
- another set of functions (there is enough of them)
- additional parameter (kind of 'cpo' for one-time-use)
- or simple break this buggy backward compatibility.

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
Reply | Threaded
Open this post in threaded view
|

Re: bug in match function

Marian Csontos
On Thu, 02 Mar 2006 16:04:16 +0100, Marian Csontos <[hidden email]> 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.

Bram and Tony, thank for your explanation.

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
Reply | Threaded
Open this post in threaded view
|

Re: bug in match function

Bram Moolenaar

Marian Csontos wrote:

> On Thu, 02 Mar 2006 16:04:16 +0100, Marian Csontos <[hidden email]> 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 -- [hidden email] -- 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         ///
Reply | Threaded
Open this post in threaded view
|

Re: bug in match function

Marian Csontos
On Thu, 02 Mar 2006 19:56:57 +0100, Bram Moolenaar <[hidden email]>  
wrote:

>
> Marian Csontos wrote:
>
>> On Thu, 02 Mar 2006 16:04:16 +0100, Marian Csontos <[hidden email]>  
>> 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
Reply | Threaded
Open this post in threaded view
|

Re: bug in match function

Marian Csontos
In reply to this post by Bram Moolenaar
On Thu, 02 Mar 2006 19:56:57 +0100, Bram Moolenaar <[hidden email]>  
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