Re: New Enter routine

[cld@xxxxxxxx]

Harry:

> ???? We are still talking at cross-purposes.

No, we're not. I see what you're trying to do. What I'm trying to get across to you, clearly without
success so far, is that what YOU are trying to do is NOT POSSIBLE.

> If the coding in the key
> assignment works, the spell-checker NEVER gets a $X--it gets {13} or if it
> should get {13}{10} then I'll send it that.

But "the coding in the key assignment" does NOT work. There is no "if" about it. It does not work and cannot work. The spell-checker is not *interpreting* the output of the Enter key. It is looking at that output as a string of characters -- a dumb, inert, non-executing string -- and testing it for a match with any *one* of the characters that the spell-checker recognizes, namely, Q1-Q8, ES, CrLf. Your Enter output string, "{>}0>{13}{10}", does not match any of those characters. Because there is no match, the spell-checker does nothing. (And please don't come back with, "But my string includes '{13}{10}', which is one of the recognized characters!" Your string bombs because the very first character, the Ascii-174 open guillemet, is a non-match. End of story.)

> Do you now see what I'm trying to do? To NOT send $X to the spell-checker,
> but to send {13}{10}, accomplished NOT within any U2 frame but in the KBD file.

The ONLY way to do that is, um, to DO IT: 28=[255+48+68], where "[255+48+68]" represents
the 3-byte sixteenth note character used to assign CrLf in the KBD file.

See what I mean now? You're erroneously assuming that the spell-checker is *interpreting" the
code that you assign to Enter. It's not. The spell-checker simply tests for strings and acts
accordingly.

I'm putting to one side your further, also erroneous, assumption that bare XPL code assigned to a
key in the KBD file is executed (interpreted) when you press the key. It's not; it's simply written
out at the cursor position, as a string. But... one fault assumption at a time.

--
Carl Distefano
cld@xxxxxxxx