Marc Durdin

Least damaging response is to shorten the input context to start after the last illegal char.

I think I want to postpone this until 18.0 -- it's a pretty risky change to make this late in beta

I haven't seen this happening for a while. Since I can't repro, I will close this, and reopen if it comes back...

> * 🟥 **TEST_NEW_PROJECT_HELP ([FAILED](https://github.com/keymanapp/keyman/pull/10939#issuecomment-2012093481))**: Tested with the attached PR build (Keyman 17.0.282-beta-test-10939) on Windows 10 OS and here is my observation: 1. Created a new LDML keyboard project. 2....

I can still see this on 17.0.306-beta. Looks like it might be related to timeout because if I do it slowly, it works correctly, but if I unshift, then modipress...

I see the caps layer too. Not sure if that was what I was originally seeing. The double-tap timeout may be too long, relates to #11183?

Did some more testing, and I think the multi-tap timeout is definitely too long, and reducing it should mitigate this and #11183. We should do some research on double-tap timings.

I will retest with 17.0.310-beta and hopefully be able to close after that.

Testing with 17.0.313-beta, no change. I can still trigger the same state as in https://github.com/keymanapp/keyman/issues/10753#issuecomment-2062936553. At the end of this, the keyboard is in the Shift layer, not Caps --...

(nomenclature: a chord is two or more keys down simultaneously -- generally k1-down, k2-down, k2-up, k1-up for coherence -- which can't be done with multitap :grin:) Understand that this cannot...