Re: EOF zapper

["..." adpf@xxxxxxxx]

≪ I briefly tried Annie's version of Harry's Ascii-26 (1Ah) zapper. A
couple of differences between it and setting DEFAULT 1A=1 in Xy4|XyWin
are worth noting.

The zapper utility will delete 1A's occurring within 3-byte XyWrite
characters (for example, the "boldface" [282], which consists of Ascii
254+26+0), while Xy4|XyWin preserves those 3-byte characters. These
potentially mischievous 3-byters virtually never appear in document
files, but occur often enough in some XPL PMs. Thus, use care when
running the zapper on XPL files. ≫ --Carl Distefano


Carl--In my excitement over kill1a I must have neglected to communicate
CC-1A's purpose, which is practical and narrow, to preserve data that
follow destructive mid(text)file eofs. Every file I've ever seen that
contains such eofs--*way* too many--has come via a platform that doesn't
support the IBM extended char set or xyW compound chars, so xpl is a
nonissue. The code would already be trashed.

≪ Another difference is that Xy4 will substitute an Ascii-49 (the
character "1") for the EOF marker and all subsequent instances of 1A. The
zapper utility simply deletes them. ≫

CC-1A does one thing, exactly what the name says: copies minus 1Ah(s).
Specifically, after some error-trapping CC-1A copies the CMline argv1
in_file, less every 1Ah (including an eof eof), to the CMline argv2
out_file. Given the 1a variable, why use CC-1a and its inspiration,
kill1a, with xyW4, except that they *don't* trail garbage? Now that
reliable ways exist to zap unwanted ^Zs, whether they occurred or where
they occurred is irrelevant to me. My xpl offline reader now "do"es
CC-1A to every unix download, no muss (no detritus), no fuss
(automatically, invisibly, no interruption of pgm flow). CC-1A met its goal.

≪ ... I can't imagine why one would run this [EOF zapper] on XPL files,
or on any files to be kept in native xy format ... ≫ --Harry Binswanger


≪ Probably something only us nitpickers would think of doing, eh? One
use might be to inspect the index appended at EOF to a LOADed Help file.
There's no way to do that in Xy3. ≫ --Carl

Uuuh ... and the *practical* reasons? Maybe this betrays an uninquisitive
nature, but having seen what's past eof in loaded xyDos 4 files when
d 1a=1, I've no curiosity about examining the xyW3 counterpart.

≪ (In fact, there's no *safe* way, in Xy3, of viewing even the pre-EOF
contents of a LOADed Help file. SAving the file--an operation that's
automatic for most of us--will cause large chunks of it to be vaporized.)
--Carl

Hmmm. Large vaporized chunks would make me very unhappy; I must be doing
*something* right. I've yet to have an experience that would discourage
me from continuing to do what I always do when I finish editing a loaded
file, .HL3 included. Before proceeding I hit my xyW3 save/reload key ...

	nn=&C,s,a, ,DXXCDOBC,l,o,a,d, ,[phi],&PXCBC&0

... where !PROfile procedure &C clears the CMline after collecting the
current CMline $, CMline and text cursor positions, and va$ti; proc &0
restores them; and [phi] causes proc &P to insert the current file name.
Of course one can't save a file and call it safely without reloading. 	--a

=========================================== adpFisher  nyc
http://www.escape.com/%7Eadpf/_xypro.html ===============================