[savetheclocktower]

…when translating keys to characters.

Here's how this library is supposed to work:

require('@pulsar-edit/keyboard-layout').getCurrentKeyMap();
// {
//   KeyA: { unmodified: 'q', withShift: 'Q' },
//   KeyB: { unmodified: 'b', withShift: 'B' },
//   KeyC: { unmodified: 'c', withShift: 'C' },
//   KeyD: { unmodified: 'd', withShift: 'D' },
//   ...
// }

The properties like KeyA represent the traditional positions of keys on a US QWERTY-style keyboard. In the US, KeyA produces a when presssed. In France, they use AZERTY, and you've got to press the key called KeyQ to produce an A and vice-versa (as the example results above illustrate).

This has worked just fine for a while. Now, however, in X11 environments, the above call produces:

// {
//   KeyA: { unmodified: 'q', withShift: 'Q' }
// }

That's not truncated — that's the whole thing.

This was murder to debug because the very act of inserting logging statements in the critical code paths changed the results. Can't tell if it was a timing issue or related to some other side effects. Claude's theory is that XwcLookupString is being somewhat misused here, and was misinterpreting a tight loop (where we match up each key in the keyboard layout with its character equivalent) as some sort of composition sequence.

Originally, Atom used XLookupString on Linux exclusively. #24 moved entirely to XwcLookupString on the theory that it was better in non-Roman alphabets. (I agree in theory, but only if it actually works.) But since it doesn't work correctly when no windows are open, #26 re-introduced XLookupString as a fallback path when an XInputContext could not be acquired.

So why did this suddenly stop working right now that we've upgraded Node and Electron? I have no clue. In fact, I can't yet be certain that the effects will be the same in an Electron environment as they were in an interactive Node session. But here's what it looks like for me currently in Linux/GNOME/X11:

I'm optimistic that this will have a similar effect in Electron, even if the root causes are somehow different.

[savetheclocktower]

We have confirmation that this change fixes layout detection in Pulsar for non-QWERTY keyboards! Let's get this landed as soon as we're able.

[confused-Techie]

While certainly not my area of expertise. The changes seem to be valid, and the outcome is working for our users. I'll trust your reasoning here and say lets merge this one!