Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!uakari.primate.wisc.edu!ark1!nems!mimsy!chris
From: chris@mimsy.umd.edu (Chris Torek)
Newsgroups: comp.bugs.sys5
Subject: Re: s/A*./B/g editor bug?
Message-ID: <20306@mimsy.umd.edu>
Date: 20 Oct 89 21:19:41 GMT
References: <10036@alice.UUCP>
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 26

In article <10036@alice.UUCP> dmr@alice.UUCP writes:
>It looks wiser to attack the problem head-on, by permitting
>the r.e. null string match, but recasting the 's/.../.../g' loop
>so that if the entire r.e. matches a null string immediately to the
>right of a string replaced in the preceding iteration,
>an advance through the subject string is forced.

Interestingly enough, Emacs (Gosling, v 85 or later) gets this right.
It does not go to much effort: the solution is simply `delete the
matched text; insert the new text; if the matched text has length
zero, advance'.  (That is, I think the procedure described above is
excessively careful.  It should not matter whether the null match is
immediately rightward of a preceding replacement.)

(I did once have to fix the Gosmacs code that handled replacements of
the form

	(re-query-replace "^" "stuff")

which, if you answered `no' to the `replace this?' prompt, would
stay in the same place.  The solution is the same: move right if the
match is empty.)
-- 
`They were supposed to be green.'
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris@cs.umd.edu	Path:	uunet!mimsy!chris