Using ^ (match start of line) and \% (match column) together

[Nicola]

The following patterns both match up to column 17 included:

/.*\%17v
/.*\%17v.

If ^ is added, the two are no more equivalent:

/^.*\%17v <-- matches up to column 16
/^.*\%17v. <-- matches up to column 17

Is this a bug?

Seeing this with Vim 7.4 1-1864.

Nicola

[Nikolay Aleksandrovich Pavlov]

2016-06-07 22:45 GMT+03:00 Nicola <nvitac...@gmail.com>:
> The following patterns both match up to column 17 included:
>
> /.*\%17v
> /.*\%17v.
>
> If ^ is added, the two are no more equivalent:
>
> /^.*\%17v <-- matches up to column 16
> /^.*\%17v. <-- matches up to column 17

You are treating this wrong. First original patterns matches up to
column 16 (inclusive) *and* has a zero-width match after column 16
which (as any other zero-width match) makes &hlsearch highlight column
17. Second original pattern matches up to column 17 (inclusive).

I.e. first original pattern has *two* matches (one of which uses the
fact that `.*` may match zero characters), second has *one*. Putting
`^` at the start rejects one of the matches.

In any case *do not use &hlsearch as the **only** instrument to
determine where is the match*. You cannot distinguish two consequtive
patterns with one, you also cannot say whether pattern matched some
character or it has zero-width match at some position. There are also
other tools: `:s` with `\=` and `submatch()`, `match*()` functions
family, `n`/`N` normal-mode commands. Though it may be a bug that `n`
can jump to that zero-width match, but `:%s//\=Echo(submatch(0))/gn`
shows only the first one (`function Echo(str)|echomsg
string(a:str)|endfunction`).

>
> Is this a bug?
>
> Seeing this with Vim 7.4 1-1864.
>
> Nicola
>
>

> --
> --
> You received this message from the "vim_use" maillist.
> Do not top-post! Type your reply below the text you are replying to.
> For more information, visit http://www.vim.org/maillist.php
>
> --- You received this message because you are subscribed to the Google
> Groups "vim_use" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to vim_use+u...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Nicola]

On 2016-06-07 20:47:07 +0000, Nikolay Aleksandrovich Pavlov said:

> 2016-06-07 22:45 GMT+03:00 Nicola <nvitac...@gmail.com>:
>> The following patterns both match up to column 17 included:
>>
>> /.*\%17v
>> /.*\%17v.
>>
>> If ^ is added, the two are no more equivalent:
>>
>> /^.*\%17v <-- matches up to column 16
>> /^.*\%17v. <-- matches up to column 17
>
> You are treating this wrong. First original patterns matches up to
> column 16 (inclusive) *and* has a zero-width match after column 16
> which (as any other zero-width match) makes &hlsearch highlight column
> 17. Second original pattern matches up to column 17 (inclusive).
>
> I.e. first original pattern has *two* matches (one of which uses the
> fact that `.*` may match zero characters), second has *one*. Putting
> `^` at the start rejects one of the matches.

Crystal clear now. I was fooled by the help, which states:

To match the text up to column 17:
/.*\%17v
Column 17 is included, because that's where the "\%17v" matches,
even though this is a /zero-width match. Adding a dot to match the
next character has the same result:
/.*\%17v.

The last sentence led me to think that the two are equivalent.

Thanks!
Nicola

[Nikolay Aleksandrovich Pavlov]

I would say that help should be fixed, zero-width match at column N
does not ever include column N.

>
> Thanks!