[Date Prev][Date Next][Subject Prev][Subject Next][
Date Index][
Subject Index]
Thanks, Joel!
- Subject: Thanks, Joel!
- From: OkAnnie@xxxxxxxx
- Date: Sat, 29 Apr 1995 20:22:40 -0400
Hi, Joel Roth: I can't answer many of the issues you raised, but
let me offer a few possible solutions, starting with the
simplest.
"I never did really understand what those NI calls were supposed
to do."
NI lets you avoid .kbd conflicts by overriding BIOS key
assignments
(especially needed for the Alt cursor keypad and keys like
Pause/Break).
"Keyboard definition files: Mistakes here are death in a fast
machine, because the error message is practically invisible."
Don't know if this is true in v4, but to debug .kbd files in v3,
loading with the "ldkbd" command instead of "load" keeps the
error message displayed till the next keystroke.
"We all know what a pain it is to write programs in XPL."
Speak for yourself! I have to force myself to *stop* writing
xpl, and don't think I'm alone. Alas, the only decent
documentation, Herb Tyson's brilliant "XyWrite Revealed," is out
of print, and TTG marketing practices make the demand for a v4
revise underwhelming. Remaindered copies of the only third-party
xyWrite 4 macro manual have been collecting dust on the shelves
of a bookstore here for months.
"That said, XPL is *great* for what it was designed--customizing
the Xywrite user interface. Most of these programs are fairly
small."
One chained xpl program I wrote runs to 50,000 bytes. XPL is as
restricted or expansive as you want to make it. Here are some v3
keyboard assignments that make it easier. Of course, always work
in expanded mode (may be called something else in v4). "{" and
"}" represent euroquotes and "E" = epsilon/ascii 238, and "o|" =
ascii 13; replace hashes with whatever's appropriate:
34=XP,SI,{,L,B,#,#,#,#,},CI,CL,CL,CL,CL,CL,CL,CL
35=XP,SI,{,p,v,#,#,},CI,cl,cl,cl,cl,cl
19=XP,si,{,e,i,},ci
45=XP,SI,{,i,f,{,i,s,#,},E,{,i,s,#,},=,>,0,},{,G,L,#,#,#,#,}
,"o|",{,e,i,},CI,
PW,PW,PW,PW,PW,CL,CL
46=XP,SI,{,i,f,(,{,p,v,0,0,},),=,=,0,0,},{,G,L,#,#,#,#,},"o|
",{,e,i,},CI,CL,C
L,CL,CL,CL,CL,CL,CL,CL,CL,CL
This changes the preceding two characters in text to a function
symbol and leaves it on @F to repeat if you wish:
68=GT,XD,DF,CL,CL,DF,SV,f,XD,BC,p,f,u,n,
,&F,XC,BC,GT,RC,DF,CL,DF,SV,f,XD,CR
The &F refers to the file !F2CL:
{pvF}{ex} which has been written to memory by this command
in startup.int:
BC ldpm c:\x3\!f2cl &f XC
This is a v3 sequence; I believe v4 has a function to put text on
the command line that probably involves getting into dialog box
junk.
"XPL programs print to file with STRIP.PRN to collect footnotes,
then I run another utility to delete the LF characters the print
driver insisted on including in the text."
STRIP.PRN *should* leave only whatever you assign as line and
paragraph endings, respectively:
LE<
PE<
... should leave nothing, joining the words at the end and
beginning of lines and paragraphs. Alternatively, after the < you
could use ascii 13 or 10 or both or a space.
"Another client needs two spaces after a period. A shareware
utility called
SNR (search 'n replace) does this fine, and I tell it to ignore
periods in such uses as Dr., U.S., Aug., etc. (Of course perl
could do this, too) Trying to do this in XPL would be a
nightmare."
What am I missing? Unless I misunderstand, this should be an xpl
piece of cake. I'd reduce all sentence endings to a single space
(some may have more than one space), do one "ci" to convert that
to a double space, then run the exceptions you normally use.
Maybe this (which I haven't run) is what you mean by an xpl
nightmare, but I find writing this stuff soothing:
BC ci _. _. _{LBcr1}XC {if@not({er})}{GLcr1}
{ei}BC ci _? _? _{LBcr2}XC {if@not({er})}{GLcr2}
{ei}BC ci _: _: _{LBcr3}XC {if@not({er})}{GLcr3}
{ei}BC ci _! _! _{LBcr4}XC {if@not({er})}{GLcr4}
{ei}BC ci _.) _.) _{LBcr5}XC {if@not({er})}{GLcr5}
{ei}BC ci _?) _?) _{LBcr6}XC {if@not({er})}{GLcr6}
{ei}BC ci _:) _:) _{LBcr7}XC {if@not({er})}{GLcr7}
{ei}BC ci _!) _!) _{LBcr8}XC {if@not({er})}{GLcr8}
{ei}BC ci _.] _.] _{LBcr5}XC {if@not({er})}{GLcr5}
{ei}BC ci _?] _?] _{LBcr6}XC {if@not({er})}{GLcr6}
{ei}BC ci _:] _:] _{LBcr7}XC {if@not({er})}{GLcr7}
{ei}BC ci _!] _!] _{LBcr8}XC {if@not({er})}{GLcr8}
{ei}BC ci _. _. _XC {lb
}BC ci _? _? _XC {lb
}BC ci _: _: _XC {lb
}BC ci _! _! _XC {lb
}BC ci _) _) _XC {lb
}BC ci _] _] _XC {lb exceptions list:
}BC cia _Dr. _Dr. _XC {lb
}BC cia _U.S. _U.S. _XC {lb <- end-of-sentence U.S.?
}BC cia _Aug. _Aug. _XC {ex}
"I was quite intrigued by Annie Fisher's discussion of
Postscript, although
I'm not quite ready to invest the time."
Windows ATM is a nobrainer typographic godsend. xyDos, however, is
PS-numb--primitive support: EPS files must be coded into disk
files manually and won't display, etc. Dan Kanagy suggested the
ideal type solution--a Tech
Group-SoftMaker font engine collaboration--to Kenneth Frank and
got zero response. Short of real support, using PS effectively
with xyDos does require a substantial investment of time. For me,
it's been worth every hour invested, but if xpl puts you off you
may not have the patience for PS. Ross
Smith's delightful "Learning PostScript: a visual approach"
(Peachpit Press) is everybody's favorite primer.
If any of this is of use, you can take it as thanks for your tip on renaming
SHIFT, CTRL, and ALT in .kbd files. Ins and Del keys next to my
(4 col x 3 row) function keypad have always gone to waste because
I sort of knew you could do that, but before reading your msg
never had the nerve to throw out
SHIFT, CTRL, and ALT entirely. I just did and, lo, nothing weird
so far and I finally have an extra CTRL and ALT where I need
them. (I can't imagine doing without function keys, or the "("
and ")" assigned to my unshifted [ and ] keys. "[" and "]" are
Shift [ and ]; "<" and ">" are Alt, freeing up the shifted comma
and period for the comma and period that should be there;
guillemots are Ctrl; and "{" and "}" are ShiftAlt.)
"Another `abandoned' product is Borland's Sprint, which I
understand has an excellent formatter and text processing tools."
As penance for passing up two copies of Sprint that I thought a
year ago were overpriced at $20 each, I torture myself by
browsing remaindered Sprint manuals. When I get to the parts
about writing Sprint macros in C, I kick myself for my dumb
judgment.
"I don't think we have much hope of getting Xy just like it was
with the one extra feature we wanted, since that `one feature' is
probably different for everyone."
Amen! --annie
========================== annie fisher nyc