Re: Case change bug workaround

["..." adpf@xxxxxxxx]

≪	[...I]n Xy4 changes made via one of the case-change commands
(LC|UC|CC) aren't detected as modifications to the file. The error occurs
erratically, in my experience, but when it does happen and a SAve command
is issued, the case modifications, treacherously, are not written to
disk. XyWrite simply prompts the user to "Proceed", so that if the file
is later ABorted, the modifications will be lost. The workaround is to
force a modification before SAving; typically this is done by inserting a
single character in the text then immediately back-deleting it. The
keyboard assignment would look something like:
	nn=GTSI, ,BDSA
≫ --Carl Distefano 

Carl--Changing the TI state is unnecessary. As I pointed out in the
earlier discussion, the problem with that .kb4 sequence is the use
of a char that xyW doesn't automatically insert in text SI'd. Give
or take a DX/DO, in .kb4 ...
	nn=GT,[*asc 13*],BDSA
... is efficient, although I quite agree about the undesirability
of xpl that tampers with text. (Acceptance of basic procedures that
do so unnecessarily rather perplexes me. My procs that detect TI state,
CMline cp, and v3 va$tx--!profile--don't mess about in text at all.)

≪	This uses the antediluvian func SV to save a zero-length DeFine
block ("DFDF") to the chosen Save/Get, then inserts it in text with
"GT@1". ≫

Ah, yes, DFDF. In v3 xpl, where the UD buffer can strain memory, this
routine that clears it can make or break a long program:
	GT XD DF DF RD XD

============================= adpFisher  nyc