Re: Substitute EOF marker

[Robert Holmgren]

** Reply to note from Dorothy Day

> The main use of bypassing the 1A of course is to be able to read past
> one that's embedded in a file. But if you can't remove/replace the
> character, if you edit and save it in Xy/NB, it gets truncated at the
> Ctrl-Z. By substituting another character, you can safely save the file
> without loss. So why not get rid of the thing altogether? Neither
> program has gone that far yet, though other programs seem to do just
> fine without this anachronism. It's a mystery to me. We have to invent
> little routines to save Xy/NB files without Ctrl-Z to upload for email,
> for pity's sake.

There are some very unsettling problems when you read past the 'EOF'
Ascii-26 character in certain XyWrite files, and I don't mean that you see the Document
Info either! (I.e., if you have DocInfo turned on, with default IO). DocInfo is
harmless, who cares. The real danger is with
Help files.

Normally, when you LOAD a Help file, data about each routine within it is indexed by
XyWrite, and this index is stored on disk at the end of the file, right after the Ascii-
26. You can easily verify this just by LISTing any LOADed Help file. These indexes are
what make the Help files so incredibly fast: the index gets cached, and you get direct
disk access.

(In case you're interested, and just so this gets publicly documented someplace once, the
indexes list information in this order [all values in hex]: Length of FrameName(s),
FrameName(s) as a string, Frame
Type in hex, Offset of opening Ascii-1 or Ascii-2, an Ascii-0 separator, number of bytes
to read until first "{" character of next-following frame, length of Index entry itself,
Ascii-0 separator. Whereas this isn't all that interesting, it tells you fairly clearly
what data gets checked -- and what does not get checked -- when XyWrite LOADs a Help file,
and therefore represents a short list of _all_ the possible causes of bad LOADs: bad
frame types, bad sets of {{ and }} curly braces, bad opening Ascii-2s, illegal FrameNames
like e.g. "{{53rdroutine}}" -- its gotta be
"{{5,3rdroutine}}" or "{{5Thirdroutine}}". In other words, it ain't bad syntax
that's
crashing your LOAD, it isn't mismatched IF...ENDIFs, it isn't a whole raft of things, but
just an item on the short list above.)

Obviously, XyWrite can't function without these indexes! Now, if you enable reading past
EOF, the index will be visible to EDITOR, and even though some characters (e.g. Ascii-0)
will not display, or will be literally edited out of the copy in the work window, Help
will still function properly -- _until_ you make changes to Help and attempt to SAve those
changes and re-LOAD! At that point, Help will no longer work properly, at least from the
location of the edit to the end of the file.
User will commence to go nuts at this point, because user will not know what is wrong.

This anyway is the way it works in Xy4. Active writers/manipulators of
Help files must not set default 1A=1! Somebody else should check NB for this behavior.

My point is that 'EOF' is no frivolous little thing, no anachronism, but a key mechanism
for maintaining internal control over some of Xy function. Hate to repeat myself, but we
should have the benefit of a Tech
Support person here, if this list is going to be the main avenue of communication between
TTG and users. TTG shouldn't skimp on this. Ken is no substitute for the real thing!

-----------
Robert Holmgren
-----------