Future-proofing the past for KB primitives

I don't foresee someone amassing a large number of production versions and picking through them to find 'just the right version' for some quirk or tweak. The (much) more likely scenario is bouncing between a perhaps large number of betas and the prod version. This represents a relatively new situation. In the past, you rarely put out beta. There was the 'prod' version, a 'new prod version' and occasionally a beta or two.

These days, you don't operate that way. You have changed your development habits over the last few years to create many, many more beta versions and fewer prod releases.

You are right; we can't accommodate all possible what-if scenarios. But we can't accommodate all scenarios of ANY kind. That is true no matter how many developers were working on the code. It can't be done.

It's one thing to say "we'd can't do everything" which is obviously true, and saying that you won't try to protect users from obvious and foreseeable run-time issues. Users are mere mortals and will make mistakes. Trying to help them escape the fallout from an innocent (but likely) mistake is just the "nice" thing to do.

Running into prod/beta version conflicts is a foreseeable issue. Only question is, do you want to take time out from other activities to insert some "niceness" code to help them.

I am not going to overly worry about it, but I feel it's important to identify run-time issues. Even if you choose not to do anything about an issue, that's not the same as saying the issue doesn't exist.

Not mentioned yet : Start BETA.exe -I TEST and choose unique KB Table .
Both Production and TEST Instance can be run in parallel with different KB .

George, I didn't want to 'overspecify' things, because we both know the most innocent of comments can blow up into a controversy, a thing I don't want.

There is a 'dumb' way to handle this, and a 'smart' way. Naturally, a 'smart' way takes more work. And, the more work, the less likely that you will want to implement it.

Since I don't really know how interested you and other users are in the whole idea, I can give you suggestions. Here is what comes to mind:

1. When a key is mapped, you have a chance to test most or all of what was entered at the time the mapping is made. Right now, you do a limited amount of checking, like looking for mismatched parens. If you could harness your existing keyboard execution function to run in 'verify mode', you could 'pretend' to execute a key mapping - only it wouldn't actually 'do' anything, except for seeing if the mapping were valid. In that way, nearly all 'typo'-type errors could be caught right at mapping time.

2. To help with existing mappings, you could have a new primary command of KEYMAP VERIFY to apply the validation process to every existing mapping. That would help transition to the new way of handling mappings so that you could check things that were already defined.

3. Steps 1 and 2 would deal with the 'typo' question. The only other question is what to do with undefined functions in down releases. Again, this can either be 'smart' or 'dumb'. The dumb way would be to have a checkbox to enable or disable warnings for key mapping issues. Maybe I can about this, maybe I don't. I suppose if I were running a down release and had a mapping issue, I'd want to know at first, but not for the next 100 times I press the 'wrong' key. The 'smart' way would be to have a universal keyboard primitive list, with an entry for every primitive name, and the range of releases they are valid in. If you get an undefined name, you could look it up in this list. If the name is known in some other release, you could ignore it, otherwise warn of a problem.

4. Do I expect you to do any of these things? No.

R

I can't argue against that, even if I were inclined to argue, which I'm not. Never thought of myself as "septuagenarian" myself (hard word to spell, BYW) but I have to deal with it, too.

SPFLite is so complicated, there are a lot of "cool" things that could have been a part of it, if we know 15 years ago what it was going to turn into, which is a LOT more than it was when it actually WAS "lite".

That is like my own keyboard project, which is far, far more than I ever envisioned 8 years ago. I now wonder whether I will live long enough to even document it, much less get it out into the world somehow.