Re: New U2

["Robert Holmgren" holmgren@xxxxxxxx]

** Reply to message from Harry Binswanger  on Sun, 26 Oct 2003
23:55:35 -0500


> 1. Shouldn't I keep my previous xywwweb.reg file, since that has the
> settings it's supposed to, and no new .reg entries are in 115? If so, 114
> users should be careful not to overwrite their old .reg file when they
> unzip 115.

True. KEEP your old personalized REG file -- do NOT overwrite it! It never
occurred to me, so -- Thanks for clarifying that.

> 2. What is the best procedure for moving my personal additions to 114 to 115?

Quoth README.1ST: "Append your own U2-formatted programming, if any, at the
end." Hopefully you kept your personal programming in a distinct contiguous
block. DeFine that block in your old U2, CAll the new U2 into another window,
CoPy the block from the old U2 to the new. Insert it at the end of the file.
There are sections of README.1ST that cover this briefly: "B. Users with
_pre-existing (non-XYWWWEB) U2 file_" is essentially the same thing, except
that you already merged our U2 and your programming together, which is the
efficient way to go (keep all programming in one library).

There are two potential snafus. The first is if you enabled frame {5*}, which
is the last frame in U2. By default it is *disabled*. You'd need to add
another { and } on either side of the {5*} (two on each side) to enable frame
{5*}. Its purpose is to trap any framename that you've called but which
doesn't actually exist in U2 -- the asterisk, in this context, steers any
framename that reaches this point in the file into this last frame, and dumps
it in the garbage. (When frames are called, they search through the index of
U2 that is created when you LOAD the file, and the first framename match is
triggered (i.e. the program in that "frame" is launched). Xy keeps working
through the index from top to bottom, until it finds a match. No match?
{{5*}} is a barrier that can't be crossed.

That leads to the second potential snafu, which arises when there is an overlap
between your framenames and our framenames. Overlap could be actual identity
-- by coincidence we both use the same exact framename -- or it could be a
"Match" created by the asterisk wildcard. Suppose you have a frame called
{{5sextet}} and U2 has a frame (as it does) called {{5ch*,ci*,cv*,se*}}, the
Global SEarch|Change Command -- you know,
the-one-which-is-so-much-better-than-the-native-command-that-it's-silly.
Suppose the Search|Change frame comes first in U2. It will trap any call to
SEXTET, because one of the four possible calls that triggers Global
Search|Change is "se*". Your call to SEXTET will be steered into SE*; but
because your call doesn't have the right argument (a proper SEarch string), SE*
will abort, resulting in a frantic cry for help and I don't understand. So in
this case, it would be imperative for SEXTET to come first in the U2 file.
(Note that {{5ch*,ci*,cv*,se*}} comes at the very *end* of U2, precisely
because it uses asterisks after just two characters in four possible
combinations. We've got a *lot* of potential overlap with SE* alone in U2:
setpp, setUV*, SetRegVar, settime, seeldsgt, setDT, setsi, seewz, and many more
-- not to mention Chkseq, Chr$, check32-127, ChCase, cite*, and you get the
idea. If any of those came after SE*, they'd be trapped by SE* and never
execute.)

Since our frames outnumber yours, but yours (in your mind anyway) outweigh
ours, it's your call whether to insert at the beginning or end. Technically,
it makes no difference where they go. If you're *asking* me, I'd say end,
because in that case if there's a problem and you need help, at least it won't
be _that_ problem! Do what you want. But if this comes back to haunt you and
becomes an issue _here_, the jig is up Harry! (Obviously, the thing to do is
put your frames at the end and then test that they still work. There is ZERO
time difference between having your frames at the beginning or end of U2 --
unmeasurable, which is to say less than 1/100 second. XyWrite Help files (U2,
DLG, whatever) are so fast, it's silly.)

Get it? Got it. Good.

-----------------------------
Robert Holmgren
holmgren@xxxxxxxx
-----------------------------