Re: [Using Auto-Replace to Embed Formatting Commands]

[cld@xxxxxxxx (Carl Distefano)]

Reply to note from "Avrom Fischer"  Thu, 28 Oct 2004
03:03:53 -0400

> I found auto replace could be used to insert virtually all the
> delta command I can think of from margins to tab sets to
> headers to centering to date to time to new page.

Well, you can use Auto-Replace to insert anything, de gustibus, but
it seems to me there are two big drawbacks to using it to embed
formatting commands. One is that each command, including its
arguments, has to be separately hard-coded in the SPL file, and the
number of potential arguments for all of the various formatting
commands is practically infinite. You can have Auto-Replace pairs
for LS1.7 and LS1 and LS1.5 and LS2, but sooner or later you'll need
LS1.4 or LS1.75 or whatever, and for those you'll have to revert to
the CMline. For TS commands, the number of possible combinations is
mind-boggling. For this reason, Auto-Replace isn't an across-the-
board shortcut.

The other problem is that Auto-Replace forces you to type a
gratuitous space, carriage return or other separator in order to
trigger the replacement. Usually the separator will be unwanted, so
you have to back-delete over it -- and already you have two extra
keystrokes, equal to the BC and XC needed to get to the CMline and
eXeCute a command. In terms of typing, there's not much savings.

One advantage of Auto-Replace is that the cursor stays in the text
window, so your attention can remain focused on your composition
without the distraction of jumping up to the CMline to control
formatting. But you can retain this advantage, along with the
flexibility of argumentation that the CMline provides, with a
keyboard macro that toggles eXPanded view before putting the left
guillemet, and that toggles back to formatted view after putting the
right guillemet. That way you can enter formatting values -- any
value, not just a few values hard-coded in a SPL file -- directly
into the document, always keeping your focus on the text.

A simple schema (not suitable for nested formatting) would be as
follows. I'm using keys 26 and 27 for open and close guillemets,
but obviously any two keys will work. In the KBD file code below,
"<" and ">" are stand-ins for the 3-byte left and right guillemets
used in the KBD file to produce "real" (1-byte) guillemets in text:

;; Xy4 - in TABLE=CTRL (for example)
26=XP<
27=GT>,TG

;; Xy3
26=XP<
27=GT>,WG
;;27=GT>,WGNM
;;27=GT>,SP
;;27=GT>,SPNM

With a little XPL, this approach could be refined to accommodate
nested commands as well. The following works in Xy4, with KBD-file
programming enabled via U2 frame XMACRO a/k/a XM. Issue
DECODE to decode:

XPLeNCODE v2.0
b-gin [UNTITLED]
26=NOJM2,.,P,r,s,K,b,d,A,r,g,Q2X,M, ,[,I,F,[,V,A,$,D,T,],>,0,
&,[,V,A,$,D,T,],<,>,8,],[,S,X,5,9,9,CO0,],[,E,I,],COX,P,[,S,X
,5,9,9,CO[,P,V,5,9,9,],+,1,],[255+065+069],NO[cr|lf]27=NOJM2,
{046},P,r,s,K,b,d,A,r,g,Q2X,M, ,G,T,[255+065+070],[,S,X,5,9,9,CO[
,P,V,5,9,9,],-,1,],[,I,F,[,P,V,5,9,9,],<,1,],COT,G,[,E,I,],NO
[cr|lf][cr|lf]
-nd
XPLeNCODE

The same thing can be had in Xy3, using, of course, v3 KBD file
programming techniques.

--
Carl Distefano
cld@xxxxxxxx