Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 5/3/83; site umcp-cs.UUCP
Path: utzoo!linus!philabs!seismo!rlgvax!cvl!umcp-cs!chris
From: chris@umcp-cs.UUCP
Newsgroups: net.bugs.4bsd
Subject: Re: Reg Expr bugs in vi? - (nf)
Message-ID: <2911@umcp-cs.UUCP>
Date: Mon, 3-Oct-83 00:31:02 EDT
Article-I.D.: umcp-cs.2911
Posted: Mon Oct  3 00:31:02 1983
Date-Received: Tue, 4-Oct-83 02:00:54 EDT
References: <3071@uiucdcs.UUCP>
Organization: Univ. of Maryland, Computer Science Dept.
Lines: 28

I think I've figured it out:

When you search for a string in VI, in order to ``guarantee'' that it
doesn't match the last-found version of the same string, vi attempts
to determine the first match on the current line; if the END of this
match is AT OR BEYOND the current cursor position (before the search
started) the match is discarded.  Thus:

	mississippi
	  ^
	cursor
/issi/ doesn't find the second "issi" (which overlaps the first "issi")
because it starts at the current line, finds "issi"; this goes over the
cursor position, so it searches for the next starting from AFTER the
issi!

The problem is, simply, that vi is a LINE EDITOR.  The most basic unit
is the LINE.  Occaisonally you get finer granularity, mostly from the
open/visual code.  The search code was probably hacked to make it look
like was character oriented; it's not.

(This bugs me no end when I ^Z and come back to find that my cursor is
now at the beginning of the line!)
-- 
Real:	Chris Torek, Univ of MD Comp Sci
UUCP:	{seismo,allegra,brl-bmd}!umcp-cs!chris
CSNet:	chris@umcp-cs
ARPA:	chris%umcp-cs@UDel-Relay