Re: annoyances and whatnot

["..." adpf@xxxxxxxx]

≪	I spoke to Kenny some years ago and we discussed features (while
I lobbied for ability to code uppercase into Styles [...]) ≫ --Bob Brody

Hi, Bob. I hesitate to enter this arena because I know you've wrestled
the problem for a long time and my workaround is so far short of
stylesheet control over caps you may think it laughable. But: I have a
couple of .kbd sequences that cap text that was just written c/lc. They
work rather like the .kb3 AR necessary in v3.56+ because of the partial
disabling of autoreplace. In this case, when you type, say, 
at the end of a graf, the key caps it as well as inserting the newline:

	28=XD,DF,PP,DF,GH,EL,SI,u,c, , ,CI,XC,GH,BD,BD,BD,BD,DE,[*ascii 13*],XD

(commas between funcs added for clarity, CI optional). The other--on,
say, --caps the previous word:

	57=XD,DF,PW,DF,GH,EL,SI,u,c, , ,CI,XC,GH,BD,BD,BD,BD,DE, ,XD

Those are lowest-tech, v3 sequences. The ones actually in my .kb3 call
the &C/&0 ldpms I've mentioned that preserve/restore launch state/CMline:
	28=XDDFPPDF&C,u,c, ,XC&0DE,[*ascii 13*],XD
	57=XDDFPWDF&C,u,c, ,XC&0DE, ,XD

In xyWin you might be able to get away with ...
	28=XDDFPPDFBX,u,c, ,Q2DE,[*ascii 13*],XD
	57=XDDFPWDFBX,u,c, ,Q2DE, ,XD
... but with v4's uncontrollable jumping around, one never knows.

A proper solution would involve xpl that undefines an existing text block
before acting, redefines it after. Hardly difficult--my backspace/Del
cache and block search & replace programs both do that. If you think this
approach would be of any help, I'll provide details. The XD/re-DF code
solves v3 problems, so isn't ported. ... Ciao. 			--a

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