XPL (For Robert J. Holmgren)

[OkAnnie@xxxxxxxx]

Robert Holmgren: I'll restrain myself and to what you wrote that
preceded the following will reply with only a hearty amen, saving
the supportive treatise for another day.

"... [T]hey've actually enhanced XPL significantly (it was
absolutely moribund--not a single new command that I can
recall--between II+ and
Signature). For their own convenience, of course! Exclusively due
to their own requirements flowing from the Menus; not even one
whit due to what users might have requested over the years, or
might find useful. Very few of these enhancements are documented;
you have to study DLG to figure them out--so DLG is profoundly
instructive, albeit unintentionally."

For an operation located in a city with a rich literary heritage,
TTG is remarkably uncommunicative (lest we forget, it also is the
city where the notion of boobus americanus was conceived).
Lobbying vigorously here for more
TTG v4 xpl documentation brought me disparagement from one subscriber and
KFrank and apparently caused TTG to labor mightily and give birth
to a mouse, that motley XYFUNC collection (thanks, Nathan, for
your thoughtfulness in adding an index file).

Do you keep any kind of systematic notes on what you harvest from
your examination of DLG? Have you ever considered something like
a shareware presentation of it, perhaps in collaboration with
Carl? I for one would be delighted to pay for documentation from
genuine experts, but apologize if, as
I suspect, that violates the spirit of your legendary
contributions to the xpl literature, which I've been denied:
Never had a CIS account and I forgo the luxury of toll calls to
TTG, which ignores all pleas posted here to mirror its BBS files
to a SimTel site. Your offer to post CTRLCHAR.TXT to
\pub\eann is most generous. I'd love to read it, and if you would
take the trouble to post it I'd be eternally grateful.

You make a persuasive argument for exploring v4 despite my
resistance. I now use xyDos only when I must, for mode
concatenation for html.pr4, files too big for v3 to handle
gracefully, and such, otherwise hieing back to v3, taking what I
like with me when I can. Many of the new conveniences are easily
reproduced in v3; my .kb3, e.g., already uses the equivalent of
BX for all of my frequently used commands that take const args
and provides an alternative for those like the search commands
that use variable args, without committing memory to a command
stack. TTG alienated me so thoroughly between the introductions
of xyDos and xyWin that I never ordered the latter.
The discussion here discourages me further, or rather TTG's
response does, to complaints about the draft mode font, .kbd, etc.

"Could you expand a bit on your understanding of nulls
(Ascii-0's?) in functions?"

I refer to the first byte of a three-byte combination, the null
at the beginning of any function symbol.

"... [C]haracters appeared at the beginning or end of lines--on
the line wrap, in other words--which didn't display properly, and
which the cursor would `hop over'--refuse to rest upon. Is this
what you're talking about?"

I don't give the phenomenon a second thought because I know it's harmless. If
I need to work on something hidden I just put an arbitrary return
in the too-long line to make the inaccessible available
temporarily, or deliberately break the line with a {lb
}.

"Could you give an example of a `loose partial null' that gets
`hooked to a return'?"

Not easily done. They're invisible and presumed; I know they're
there only when I find the cursor blocked from moving up past a
return either with a BD or CL. Seem to occur when a function
symbol is deleted or backspaced at a return. Cursor stalls, I
believe because the null remains.

"Also, `the single-byte char in text' is which char?"

The null that remains after R0 BD BD. My v3 xpl program that
converts two chars entered on the command line to a function
symbol for a search in xpl concatenates converted chars to an @,
for display on the CMline in a possible subsequent search and
replace. The @ ends up looking like this, to take it from the top
(underscores are delimiters and [*nnn*] is an un'netable >127
char; returns and tabs added for ... clarity [?]):
   R0 BD BD [*128*] R0 R0 R1 _ R0 BD BD [*129*] R0 R0 R1 _
   R0 BD BD [*130*] R0 R0 R1 _ R0 BD BD [*128*] R0 R0 R3 _
   R0 BD BD [*129*] R0 R0 R3 _ R0 BD BD [*130*] R0 R0 R3 _ ...
equivalent to:
   R0 (single byte)+128+001
   R0 (single byte)+129+001
   R0 (single byte)+130+001
   R0 (single byte)+128+003
   R0 (single byte)+129+003
   R0 (single byte)+130+003
It's those BDs after R0s I'd like to get rid of by being able to
enter the single initial byte directly in the xpl code. (Does
this make *any* sense?
You're certainly right about there being no lexicon.)

I wrote the program a while back and don't remember the
experimentation that went into getting it to handle 255
weirdnesses; my solution makes no kind of sense to me now, but
works--in the xpl: R0 NO BD BD, so for WL and $B the @ looks like
this:
   R0 BD BD [*128*] R0 NO BD BD _ R0 BD BD [*129*] R0 NO BD BD
_
The only insurmountable prob I've found is that I can't store the
combinations that involve ascii 13 and 17 (@6 DT $1 @8 S2 $K) as such in the
@. For the first pass, the xpl enters them from a help file with
a coordinated
   {{2 [*128*],[*129*],[*130*]}} where they are in magical
number positions. Hardly ideal.

Thanks for your attention. I look forward with great anticipation
to reading
CTRLCHAR.TXT and anything else of yours that is duplicated at
ccat (hint hint)--especially, I might add, anything from the
'89-'91 era, the golden age of DOS creativity, before the
ascendancy of you know what. ;)   --annie

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