VI - Bug or feature?????

[Hans Mulder]

In article <1244 at potpourri.UUCP > bseymour at potpourri.UUCP (Burch Seymour) writes:
 >I noticed the following strange behavior of vi and, while it's not exactly
 >a critical problem, I am curious as to whether vi is flawed, or my 
 >understanding of the way vi does searches is flawed.
 >
 >Consider the following three lines of text:
 >
 >loog loog loog loog loog loog
 >loog loog loog loog loog loog
 >loog loog loog loog loog loog
 >
 >Now search for loog using '/loog<cr>' followed by 'n' as required. Vi will
 >stop the cursor on each word in the three lines. Fine so far. Now search
 >using '/l.*g<cr>' and 'n'. Vi will stop at the first position of each line.
 >This, or so I am told, is because vi matches the longest possible pattern,
 >and the whole line matches, so the next match is on the next line. Fair
 >enough. Now the buggy part.  Position the cursor on some character other
 >than the first one on any of those lines. Then do the '/l.*g<cr>'. I would
 >expect it to stop at the next occurance of 'l' on that line. It does not.
 >It will stop at the first position of the next line. Anyone care to 
 >speculate why? And is that a correct thing for it to do?

My guess would be that there is no real difference.  The first match on the
line is the entire line, so when you ask the pattern matcher to find
another match, it reports that there are none.

I agree with you that this behaviour is incorrect.  But I am afraid it is
not easy to repair.  The cause of the problem seems to be that vi is based
on a line editor (ex, a derivative of ed).  Ex has this routine that finds
all non-overlapping matches on the current line, which is very handy for the
:s/pat/repl/g command, but not quite what vi should have borrowed.


Hans Mulder	hansm at cwi.nl	mcvax!hansm