s/A*./B/g editor bug?

[Chris Torek]

In article <10036 at alice.UUCP> dmr at 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 at cs.umd.edu	Path:	uunet!mimsy!chris