[Date Prev][Date Next][Subject Prev][Subject Next][
Date Index][
Subject Index]
Re: Programming: best ci strategy
- Subject: Re: Programming: best ci strategy
- From: Harry Binswanger hb@xxxxxxxx
- Date: Sat, 29 Oct 2011 14:04:16 -0400
Paul,
Yes, search loops are always a fallback. I'm a fiend for speed. Probably
ridiculous, since getting it requires hours to save seconds a day. But I
do need my programs to work on longish files, where they can take an
incredible 15 seconds to run to completion. And there are four or five
such that need to run in succession.
Regards,
Harry
Harry, for varying length strings
that need modification I typically use a loop program rather than a
single CI or other command. In your case, I would tend to do the
following:
start
se print[space]
if error exit [maybe return to previous position or top of the file
before exit, if desired]
" [ie, insert "]
se/f CR|LF
"
back to start
Of course, this can chew up a file that is inconsistently structured. But
the search parameters can be much more complex than shown, and a loop
like this does have the advantage that it will work if there are 10
characters or 10 thousand between "print" and the carriage
return.
Speed on a newer computer isn't much of a problem, unless
instantaneousness is a must.
Paul Lagasse
On 10/27/2011 10:40 PM, Harry Binswanger wrote:
Carl,
Thanks. This would be good for that one use. I was wondering if there was
some general way to do things more efficiently than I am. Apparently,
there's no guru's trick for such things.
Do you find, generally, that SEarch plus manipulations is as fast as CI?
My experience is that CI is always to be preferred, when it is possible
to use it.
Recently, I've had much anguish trying to use CI with [W]. One problem is
that [W] is too short, the other is that [W] is too long, so "looks
ahead" as it were to find things I didn't expect it or want it to
find.
--Harry
But two things occur to me
off the bat. First, if "." is the
only offending separator, then you could use the [-] exclusion
wildcard (reverse video "-") to construct a CHange command
that
excludes ".". Second, sometimes the only way to work around
error
567 ("Wildcards must be in the same order on both sides of a
change") is to write your own CHange command (in the form
BX se /blah/Q2 )[make the
change]).
Putting those two ideas together, I come up with:
XPLeNCODE v2.0
b-gin [UNTITLED]
{<}LBa{>}[BX_]se /[wS][w-].print
/[Q2_]{<}IF@NOT({<}ER{>}){>}
"[BX_]se/f
[wC][Q2_]"{<}GLa{>}{<}EI{>};*;[cr|lf]
-nd
XPLeNCODE
This assumes (because your examples also seem to assume) that the
material to be wrapped in double quotes alway ends with a CrLf. It
will not work on a "print" statement that occurs at the very
top of
the file (easily remedied), and it may be over- or under-inclusive
in other respects (again, hard to know without a more comprehensive
statement of the problem), but it may provide food for thought.
--
Carl Distefano
cld@xxxxxxxx
Harry Binswanger
hb@xxxxxxxx
Harry Binswanger
hb@xxxxxxxx