Re: heavy-duty search & replaces

[Carl Distefano CLDistefano@xxxxxxxx]

Reply to note from rrr@xxxxxxxx (Rene von Rentzell) Wed, 25 Mar 1998
15:15:12 +0900 (JST)

-> >Alas, I don't see a way of getting wildcards on both sides of the
-> >equation that wouldn't be very laborious, and slow. Others are
-> >welcome to try.
-> >
-> >--------------
-> >Carl Distefano
->
-> Why not using XY4, where wildcards on both sides are required. Am
-> I missing something?

Recall that we're talking about BIG search and replace strings, not limited
by the length of the CMline or the 80-character maximum that attaches to
BX...Q2 statements. (BigChg will search and replace blocks of text many
hundreds or thousands of bytes long. There are no arbitrary constraints on
length or on the number of replacements on a single pass. There *are*
limitations, of course, but they stem from XyWrite's rather archaic memory-
handling capabilities.)

If we could simply plug these long strings into a CV command, then
wildcards on both sides of the change would be a trivial matter. But we
can't (because they're too long), so it isn't. What BigChg does is to lop
off the first and last 78 characters of the search string and SEarch,
initially, for those; other techniques are used to positively identify
instances of the entire string. That's why the use of wildcards is limited
to the first and last 78 characters of the search string. Those are the
only parts that are fed to a SEarch command!

The replacement string is another kettle of fish. When BigChg finds a
match for the search string, it does a block delete and thunks in the
replacement string. Do you see now why wildcards in the replacement string
won't wash? You can put 'em in alright, but they'll be treated as literal
text -- inserted in specie right in the document! Whyzzat? Because
wildcards only work in search & replace commands (to the rest of XyWrite
they're just strings of characters like any other), and we're not using
search & replace commands in our XPL. Because we can't. Because long
strings don't work in search & replace commands, which is why we're writing
this program in the first place. In sum, you can't rely solely on the
procedure whose limitations you're trying to circumvent to cook up a new
procedure that circumvents those limitations!

BTW, it's not quite accurate to say that "wildcards on both sides are
required". Left-side-only is fine. However, when wildcards appear on both
sides, they must, according to Error Message 567, "be in the same order on
both sides of a change." Whatever that means.

--------------
Carl Distefano
CLDistefano@xxxxxxxx
http://users.datarealm.com/xywwweb/