bseymour@potpourri.UUCP (Burch Seymour) (07/19/88)
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? -Burch Seymour- ...uunet!gould!bseymour or whatever else you can conjure up ----------------------------------------
hansm@cwi.nl (Hans Mulder) (07/23/88)
In article <1244@potpourri.UUCP > bseymour@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@cwi.nl mcvax!hansm
peter@ficc.UUCP (Peter da Silva) (07/25/88)
In article <394@piring.cwi.nl>, hansm@cwi.nl (Hans Mulder) writes: > 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. I disagree. This behaviour is correct. I have used an editor on the PC that does what you suggest -- terminate closures with the shortest match -- and it's very irritating. You can't emulate long closures with a short closure regular expression, but you can do the opposite -- emulate short closures with a long closure RE. It's almost always better to use the more general method. -- Peter da Silva `-_-' Ferranti International Controls Corporation. "Have you hugged U your wolf today?" (uunet,tness1)!sugar!ficc!peter.