PFCLKBREAK also a no-op?

[Brian K. White]

> However I do see the problem.
[...]
> Inkey does not wait, which means, I'm almost never
> actually IN an inkey statement.
[...]
> Is it something that could intercept break under programmer
> control like the other things above? Or would that break the
> necessary "normal" function of breaking out of update mode
> without saving?

I think the answer to my own question is a 3rd option
to the break command.

Right now we can programmatically suspend break from breaking,
by "break off".

I would happily use that, IF it wasn't so _completely_ off. ;)

Right now, if break is off, then break keypresses are not
registered or detectable at all. They don't go onto the stack
to be detectable later either.

If break is on, it takes full effect immediately, which normally
you want.

So it should be possible to have an option that falls between
on & off. Have the trap handler fill @sk and otherwise act as
if a key were pressed, but do nothing else, like when break is
off. The cammand would be something like "break trap" or if
you're feeling particularly poetic, perhaps "break bkw" ? ;)

-- 
Brian K. White      brian at aljex.com       http://profile.to/KEYofR
+++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
filePro  BBx    Linux  SCO  FreeBSD    #callahans  Satriani  Filk!