RE: zap eof?

[OkAnnie@xxxxxxxx]

Thanks, Dorothy Day, Dan Kanagy, and Daniel Say.

The default 1a=1 option seems to be a new feature with v4.
Executing d 1A=1 or d 1A=@ from the command line or adding it as
a printer file DF with v3.52 and v3.56 produces a "Can't set
value with default" error msg.

Daniel Say emailed me a response to virtually the identical
question posted by someone else yesterday to the NotaBene list.
Jukka-Pekka Takala noted that
"setting NB to replace all EOFs with a designated character only affects
READING those characters and then only in the middle of file."

This rather puzzles me. xyW can't read or write past the normal ascii 26 (hex
1A) eof, but other apps can. If an app that doesn't respect the
xyW eof as such writes past it, when you reopen the file with
xyW, it won't display text added beyond the eof, and writing to
disk truncates text added beyond the eof. Perhaps using another
char as the eof eliminates this effect? (I'd have to reinstall v4
to test that.)

In any event, it seems that even with v4 the only way to
eradicate the eof completely is the way I've been doing with v3,
with an external utility (an xpl macro that DOes it makes it feel
like part of xyW). If I run my !XEOF macro, text I then add to a
xyW file with another app is displayable later in xyW; when I
save the file later, xyW adds a new eof at the actual end.
!XEOF's main purpose, however, is to erase the eof for
environments where the control character is a nuisance or
fatal--e.g., some PostScript printers and, reportedly, online
html checkers.

Again, thanks very much, Dorothy, Dan, and Daniel.  --Annie

====================== annie fisher | nyc | okAnnie@xxxxxxxx