RE: Memory Leak?

["Harrison, Shawn" Shawn_Harrison@xxxxxxxx]

R. Holmgren wrote:
> Here's my interpretation of your command
>  ci /{qst}WWR{note}
> XPLeNCODE v2.0
> b-gin [UNTITLED]
> [BC_]ci /{qst}[w<]MDRV[w>][wW][w<]/{qst}[w<]MDRV[w>][wW][w<]M
> DNM[w>][wC]{note}[w<]/[XC_][cr|lf]
> -nd
> XPLeNCODE

For the sake of clarity -- yes, this is what I was doing. And running
this has the same result as my original -- it bombs the file with binary
garbage.

I traded out my editor4.exe, as you suggested. No luck. Same results. It
makes the change all right, but then scrolling invariably produces binary
junk.

My comments about wildcards etc. were just in respose to your own. The
"red left-arrow" is the character in question, ASCII 13+10. I have this
character loaded on CTRL+Enter. Perhaps [CR|LF] would be an unambiguous
way to refer to this character, following what you've done in your
XPL-encode.

> The truth is, this isn't a real wildcard. Neither are the red
guillemet
> "wildcards", nor LF, nor CR.

Then why did you complain about what I was doing before as being an
"illegal use of wildcards"? I understand the use of wildcards with ci and
friends, but [CR|LF] is not bound to those rules. The way I'm using wild
W's is itself not problematic -- I can do other types of changes without
the problems I've been experiencing. In fact, I can replace the [CR|LF]
in my original command string with {*}, and the problem does not occur
(and yes, then I could simply "ci /{*}/[CR|LF]/ -- but that begs the
question of why I'm having trouble).

> My experience is, that if you obey the rules, XyWrite obeys the rules;
but
> that Xy4 can get extremely stressed when you push its parsing
capabilities
> to the edge.

That's nice in theory. But I don't see why what I was doing is "outside
of the rules" of XyWrite. I've given the program enough to work with to
sort out the wildcard W's, and the "red left-arrow" (whatever it is) is
certainly non-ambiguous.

Shawn

==========================
shawn_harrison@xxxxxxxx
==========================