> Note, however, that $MO is *not* moved
> from 0 to 1 by doing a single CC.
Huh? VA$MO indicates whether the file has been MOdified or not.
What does func CC have to do with anything?
Not the func but the command: change case. The file *is* modified in fact,
but VA$MO doesn't pick it up. As I illustrated in a post yesterday:
---------------------------------------------
This gets to one of the very, very few bugs in XyWrite: it doesn't register
a change in capitalization as a change "worth" saving. Try this. Make a NEw
file with this line:
I love XyWrite.
SAve it.
Then, without making any other changes to the file, put your cursor on the
"I," go to the Command Line, execute command CC. That should change the "I"
to lowercase. Go back to the Command Line and execute command SA. You
should see the prompt "Proceed" rather than the familiar "Done"--that's a
clue. If you now ABort the open file and open it again, the old, upper-case
"I" will be there. The change to lowercase didn't get SAved.
------------------------------------------
> Why the SUbroutine 01 when it is called only once?
Because a SUb refreshes the value of , which always holds
by default the text on the CMline when a program *starts* but
gets wiped out by a call to another frame (here, frame AF). The
SUb re-reads the CMline and stores it in S/G 05.
Thanks, that's really interesting.
> Why not have an before the first ?
Because I'm not ready to EXit yet!
> Is that to allow for having
> a zap26 call when the original window was [UNTITLED]?
Of course. That, plus I would still want to synchronize
multiple sessions, if pertinent.
I see.
> Is there any reason to use "in" vs. "contains" (238 vs. 240)?
In this particular test it is simpler, more succinct. Fewer
bytes. Faster.
> Are they exact inverses of each other?
I don't know what you mean. One (238) has the capability of
precisely testing containment position, the other (240) doesn't.
Ahhh, now that you mention it, I recall that.
That's the basic difference. There are also considerable
similarities. These expressions yield identical results:
{greater_than}-1>
{240}"blap">
{240}"blap")>
{238}"blap"{less_than}0>
In both of those couplets, the second choice is the more
succinct, and that's the one we generally use -- you'll seldom
(maybe never) find an
{240}"something")> expression in U2 because it's a
prolix test of that proposition. We try to be pithy without
sacrificing complexity -- indeed, pithiness is required if you
indulge complexity, because XPL memory has real limits.
This is all quite helpful. Thanks Robert.
Harry Binswanger
hb@xxxxxxxx