Re: XyWrite Development

[OkAnnie@xxxxxxxx]

Kenneth Frank: Glad to have "+" and ";" clarified. I pored over
my xyDos 4 manuals last night trying to determine their
significance. In environments hostile to upper-128 chars I prefer
to represent 174/175 with {/} braces since they're also
single-byte, insignificant to xpl, and less likely than double gt
and lt to be confused with boolean symbols.

Again, to bring back the discussion of undocumented function
redefinitions to the original context--TTG strategy in persuading
v3 users to upgrade--I cited
UD and my .kbd problems merely as the first mines I tripped over.
My .kbd and xpl files enter many codes besides modes as text, in
expanded mode in xpl, but not .kbd, files. The manuals don't
mention the removal of the SD function, transformed apparently to
JM (TMACRDEF). Chet Gottfried just tripped over that one, and if
I'd stuck around I would have too. What other uncharted landmines
lie in wait? I think answering that is TTG's job, not users'.

When I inquired about the issue in my first posting ever to the
list, the first subscriber who replied said, "I had a lot of XPL
code under III+ which
I ported (little by little, over a period of many months) to
Signature, and thence to XyWrite 4." ... Period of *many months*?
That doesn't make it sound like I'm overstating the problem. I
can't spare that much time to test my own by trial and error. And
I might as well learn, say, winWord, as xyWin if my v3 .kbd is so
incompatible it's unusable. Even its alphanumeric assignments are
idiosyncratic, and xpl macros attached to keys make my xyWrite
interface far distant from the one defined by the default
keyboard, which I never learned. I don't care to do so to make
the transition.

I believe a coherent, comprehensive TTG analysis of v4 function
redefinitions would do more to persuade v3 hardnoses to upgrade
than punishing us. I hope that's what Tech Support is preparing.
--annie

========================== annie fisher  nyc