Re: Putting 2-char. func.call in CM-line argument

["Carl L. Distefano" CLDistefano@xxxxxxxx]

** Reply to note from Eric Van Tassel <101233.342@xxxxxxxx> Fri, 28
Feb 97 06:51:10 +0000

> Harry Binswanger kindly showed me that you can use {11} (the "masculine" symbol)
> together with the string /fn to search or replace, e.g.
> 			se/fn *{11}bc*
> (where {..} = ASCII call-out number, and ** are the begin-end separators for a
> search)
> if keyed on the command line and executed with F9, will put the cursor on each
> successive instance of the BC function call. .... Similarly,
> after the "a" of BC cia. But
> 			se/fn *{11}bccia*
> wouldn't work. The reason (I finally figured out) is that the highlighted "BC"
> which depicts the function call in a program file on screen always has an
> immutable, untouchable space after the "C"....

Ha! The "space" after the "BC" is an illusion; in fact, the whole
thing is illusory: No BC, no space, and no MoDe BOld. It's all
video legerdemain, courtesy of EDITOR.EXE. What you're seeing, in the
case of func BC, is really Ascii 255+129+31; you can verify this by
inspecting it in a non-Xy text editor, or in a hex editor like Vernon
Buerg's LIST.COM.

In XyWrite, Ascii 254 and 255 are control characters with a
distinctive, combinatorial property: they merge with the next 2 bytes
to form a cohesive, 3-byte unit -- a new entity. When the first byte
is 255 and the middle byte is Ascii 128, 129 or 130, the entity is a
function. When displayed, functions occupy 3 visual slots, but many
such characters occupy only 1 slot (e.g., the SEarch wildcards),
whereas others take up more (e.g., in non-WYSIWYG views, symmetric
quotes display as bold [264] and [265] -- 5 visual slots). When such
characters are manipulated as text strings, their apparent length and
visual content are of no consequence. It's the 3 underlying bytes that
matter.

Robert Holmgren analyzes XyWrite control characters at fascinating
length in CTRLCHAR.TXT, available here in one of the public files
sections. Highly recommended for anyone, programmer or not, who wants
to appreciate this important part of XyWrite's sub-surface operations.
As your example shows, enough of the iceberg protrudes to crash even
apparently unsinkable operations, such as a straight-forward SEarch or
CHange. 

BTW, you can put functions on the command-line in true 3-byte form (so
that they display as they do in text), and use them to perform SEarch
and CHange operations, etc. The PFUN routine I sent you the other day
will do it -- puts the function at the cursor location, whether in text
or on CMline. Alternatively, Robert has a dedicated routine for CMline
funcs. It makes sense to have a single visual representation of funcs
for text and CMline. Besides, Ascii-11 is hard to remember -- and
sexist to boot! Oh, yes!

The sex stereotyping inherent in the allocation of gender-indicative
Ascii representations in XyWrite is worth remarking. Ascii-12, the
"female" characater, is relegated to the passive (and by extension
nurturing and protective) role of causing warning messages on the
status line (read: inferior status -- physically inferior in the
Windows interface!) to _blink_ (the seductive implications
of this action, with its debasing subtext, are difficult to ignore);
whereas the "male" Ascii-11 is assigned the archetypically active role
of "penetrating" the 3-byte composition of "functions" -- the meme
itself carries, indeed embodies, the active denotation -- and
"flagging" (the imputation of potency to the Ascii-11 subsuming,
inevitably, the dialectic of impotence) such functions -- the
spermatozoa of virtually every XyWrite operation, and by logical
extension, the seed from which every XyWrite-produced text springs --
in "text". Transparently sexist!



--------------
Carl Distefano * * * CLDistefano@xxxxxxxx
--------------