Re: Long strings in CI ///

[Harry Binswanger hb@xxxxxxxx]

Oh, I didn't understand that about s/g K. So I could
do:




and that would be the replace string? Have to try it.


As to my routine, I don't see how it could fail, provided the separator
(%% in my example) is completely unique. Here's what's going on, using ^
as the separator, ABC as the replace string, F for the original find
string, and dots for non-ABC text.


original condition of document


........F...........................

.................................F...

.........................................

..F...............................


The first step is CI /F/A^/ and produces:


........A^...........................

.................................A^...

.........................................

..A^...............................


The second step is CI /^/B^/ and produces


........AB^..........................

.................................AB^..

.........................................

..AB^...............................




The third step is CI /^/C/ and produces


........ABC..........................

.................................ABC..

.........................................

..ABC...............................


Dependencies that I can see:


1. The separator string must be absolutely unique--ideally something
like: @_z^q$a


2. If the separator string is too short, you risk a false match. E.g.,
suppose the separator string is %%. If your document is this:


........F%..........


then after the first CI you would end up with


.........A%%%.......


which smells of trouble to me.


But it's all about the uniqueness of the separator string, I
think.


After that's established, things can't go wrong, because after the first
replace, each subsequent search field is just the separator you put there
in the previous step (as in my example: CI /^/B^/


But perhaps you can foresee contingencies that I can't.


Anyway, will try BigChg right now.


Thanks,

Harry










Reply to note from Harry Binswanger
 Tue, 30 Nov

2010 22:54:18 -0500


> I'm skeptical of BigChg being what I want, because it expects

> you to DeFine the long text for the replace string. This is to

> be done under program control, and if I'm going to use a
SEarch

> and DeFines, I might as well do that directly and print the

> replacement string (which is the alternate way I've been doing

> it in some cases). That way is considerably slower than
CI.


I'm not sure I understand this. The replace string is in S/G K; the

search string is what's DeFined. In any event, there are many

possible ways to grab the input (for example, the command could be

structured as BIGCHG /longstring1/longstring2/ in a U2L window --

that would be an easy mod), but the underlying procedure in BIGCHG

is rock-solid XPL. I'm skeptical of your multiple CI procedure,

because I'm not sure how you are verifying that the pieces you're

replacing add up to unified occurrences of the whole long string as

opposed to fragments scattered across the document. If you come up

with a way that's CI-fast and dead accurate, I'll be interested to

hear about it.


--

Carl Distefano

cld@xxxxxxxx




Harry Binswanger
hb@xxxxxxxx