:il[ist] with numeric patterns

23 views
Skip to first unread message

esquifit

unread,
Apr 24, 2012, 5:11:47 PM4/24/12
to vim...@googlegroups.com
According to the help (:he :ilist)
:il /foo/
would find all occurrences of the string 'foo' while
:il foo
would find all occurrences of the pattern \<foo\>, that is, 'foo' as a
whole word.

I've found that when the pattern is a number this is no longer the case:
:il /20/
finds all occurrences of the string '20' as expected, but
:il 20
gives an "E389 Couldn't find the pattern" even if '20' does occur as a
whole word. In fact,
:il /\<20\>/
effectively finds all occurrences of '20' as a whole word.

Is this a bug or am I missing something?

gVim on Windows 7
VIM - Vi IMproved 7.3 (2010 Aug 15, compiled Aug 18 2011 14:48:22)
MS-Windows 32-bit GUI version with OLE support
Included patches: 1-284

Jürgen Krämer

unread,
Apr 25, 2012, 12:58:41 AM4/25/12
to vim...@googlegroups.com

Hi,

esquifit wrote:
> According to the help (:he :ilist)
> :il /foo/
> would find all occurrences of the string 'foo' while
> :il foo
> would find all occurrences of the pattern \<foo\>, that is, 'foo' as a
> whole word.
>
> I've found that when the pattern is a number this is no longer the case:
> :il /20/
> finds all occurrences of the string '20' as expected, but
> :il 20
> gives an "E389 Couldn't find the pattern" even if '20' does occur as a
> whole word. In fact,
> :il /\<20\>/
> effectively finds all occurrences of '20' as a whole word.
>
> Is this a bug or am I missing something?

as far as I understand it, :ilist is supposed to be used for searching
for keywords like identifiers in a programming language. See the fourth
paragraph at ":help include-search".

With the slashes around the pattern you explicitly tell Vim to search
for only a part of a keyword, but without the slashes Vim searches for a
word (in Vim's sense of word, see ":help word") that is also a keyword.
Presumably, without looking at Vim's source code, a keyword must start
with a letter, so '20' would not be found.

Regards,
J�rgen

--
Sometimes I think the surest sign that intelligent life exists elsewhere
in the universe is that none of it has tried to contact us. (Calvin)

esquifit

unread,
Apr 25, 2012, 4:36:47 AM4/25/12
to vim_use
This was what I thought at first. However ":he word" says:

*word*
A word consists of a sequence of letters, digits and underscores, or a
sequence of other non-blank characters, separated with white space
(spaces,
tabs, <EOL>). This can be changed with the 'iskeyword' option. An
empty line
is also considered to be a word.
*WORD*
A WORD consists of a sequence of non-blank characters, separated with
white
space. An empty line is also considered to be a WORD.

My 'iskeyword' is
@,48-57,_,192-255
so digits are there (48-57). I found nothing about words having to
begin with a letter, although what you are saying makes sense. In this
case the documentation should be updated.

Andy Wokula

unread,
Apr 25, 2012, 4:37:18 AM4/25/12
to vim...@googlegroups.com
Am 24.04.2012 23:11, schrieb esquifit:
> According to the help (:he :ilist)
> :il /foo/
> would find all occurrences of the string 'foo' while
> :il foo
> would find all occurrences of the pattern \<foo\>, that is, 'foo' as a
> whole word.
>
> I've found that when the pattern is a number this is no longer the case:
> :il /20/
> finds all occurrences of the string '20' as expected, but
> :il 20
> gives an "E389 Couldn't find the pattern" even if '20' does occur as a
> whole word. In fact,
> :il /\<20\>/
> effectively finds all occurrences of '20' as a whole word.
>
> Is this a bug or am I missing something?

Many `:[range]' commands accept an optional count as the first argument,
apparently this is true for :ilist also:

:il 3 20

finds `20' in the text. Not sure if the count has any purpose.

--
Andy

John Beckett

unread,
Apr 25, 2012, 6:36:50 AM4/25/12
to vim...@googlegroups.com
Andy Wokula wrote:
> Many `:[range]' commands accept an optional count as the
> first argument, apparently this is true for :ilist also:
>
> :il 3 20
>
> finds `20' in the text. Not sure if the count has any purpose.

Thanks, I was going to propose :ilist to the OP but did not when
I could not get it to work.

A quick test shows you need a bang to get all numbers, including
those in comments as documented.

In a new buffer (':new') with these three lines:
123
> 123
let s = '123'

using ':ilist 1 123' shows only lines 1 and 3, while
':ilist! 1 123' shows all three lines.

John

esquifit

unread,
Apr 25, 2012, 8:47:01 AM4/25/12
to vim_use
On 25 Abr, 12:36, "John Beckett" <johnb.beck...@gmail.com> wrote:
> Andy Wokula wrote:
> > Many `:[range]' commands accept an optional count as the
> > first argument, apparently this is true for :ilist also:
>
> >      :il 3 20
>
> > finds `20' in the text.  Not sure if the count has any purpose.

Thank you! This is Interesting but tricky and not at all obvious. In
fact the help doesn't say anything about an optional count:

:[range]il[ist][!] [/]pattern[/]
Like "[I" and "]I", but search in [range] lines
(default: whole file).
See |:search-args| for [/] and [!]. {not in Vi}


> Thanks, I was going to propose :ilist to the OP but did not when
> I could not get it to work.
>
> A quick test shows you need a bang to get all numbers, including
> those in comments as documented.
>
> In a new buffer (':new') with these three lines:
> 123> 123
>
> let s = '123'
>
> using ':ilist 1 123' shows only lines 1 and 3, while
> ':ilist! 1 123' shows all three lines.
>

This is also interesting. When I checked the help for 'search-args' I
read
[!] When included, find matches in lines that are recognized as
comments.
and I stopped reading. I didn't pay any attention to the explanation
about [!] and 'comments' because I thought it would not be relevant
for a buffer with no particular file type. Now I see I was wrong,
since vim has always some notion of what a comment is according to the
settings in the 'comments' option.

Thank you everybody for the help.
PS: ":ilist! 0 123" also works. I prefer this as it makes slightly
more clear that 0 is just a dummy value.
Reply all
Reply to author
Forward
0 new messages