[Date Prev] [Date Next] [Thread Prev] [Thread Next] Date Index Thread Index Search archive:
Date:Mon Oct 30 19:26:57 1994 
Subject:Search and Replace Problems in the new VED in V14.5 
From:"A.Sloman" 
Volume-ID:941101.01 

Although the new search mechanism in VED in V14.5 is based on an
excellent new regular expression matcher and many of the old facilities
have been usefully generalised, there is a serious problem that
users need to be warned about.

1. Interactive search and replace misses some options.

If you use ENTER s/string1/string2/ and don't accept all the options,
you may miss some occurriences of string1 if the search wraps.

E.g. For a demonstration of the bug:
	TEACH ELIZA
	goto line 635
	ENTER s/TEACH/TTTT/

do not accept any of the options to replace (i.e. keep pressing DEL)
until it has wrapped and offers you an option at the top of the file.
Then accept it (i.e. press RETURN).

It then STOPS there and offers you no more options, even though there
are several more occurrences of "TEACH"

This bug is serious because people may think they have found all
instances in the file when they haven't. (That's how I discovered the
bug!). So after interactive search and replace CHECK that there are no
locations that have been overlooked.

I assume this will be fixed in the next release.


2. You can get offered the same replace option more than once.

The above problem does not occur if you accept a replace offer BEFORE
the search wraps to the top of the file.

But in that case there's a different bug: you get offered the same thing
to replace more than once, IF you have refused some offers between the
start point and the first accepted offer. I.e. after it wraps, it
continues searching past the original start location, offering you
previously rejected replacement options.

The original ved mechanism was full of nasty kludgy hacks to deal with
these sorts of cases. I suspect the excellent cleaning up that has been
done has been a bit too zealous.

Without being able to look at the new sources, my guess is that both
problems arise indirectly out of a decision to change ved_s so that it
finishes by taking you back to the last location at which you accepted
a replacement offer, rather than simply leaving it at the last location
displayed.

I can't see the point of that decision: it seems more natural to me that
the last displayed location should be left on the screen rather than
arbitrarily switching back to the last location at which you made a
change.

Anyhow I suspect that the information being used to record the last
position at which something was changed is messing up the records of
which locations have already been shown to the user, which depends on
where you started, not where you made your last change.

So anyone using "ENTER s" must now be VERY careful.

Another change that I personally find very irritating is that backward
search now WRAPS round to the bottom of the file by default, making it
harder to tell whether an occurrence of an identifier is the first in
the file. (You prevent the "ENTER\<string>" command from wrapping you
now have to type a closing delimiter and the -wrap flag).

I have a partial work-around, by providing an extension to the caseless
search facilities (ved_ss) in which backward searching does NOT wrap
by default. I'll broadcast the code separately later.

Meanwhile, the following will replace the default backward search for
the previous search string, as mapped onto "ESC \", with a version that
does not wrap.

	;;; Make "ESC \" Equivalent to "ENTER\\ -wrap"
	vedsetkey('\^[\\', veddo(%'\\\\ -wrap'%));

Cheers.
Aaron