Note: linux behavior is not strange, it is deliberate, see this:
https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/a4a08f98c17b23ad54b5e361ffc0280e2ea8e0c3/platforms/unix/vm-display-X11/sqUnixX11.c#L2065

It was introduced with 1b837f9

If we want to fix it, we can just enclose this piece of code with #ifdef PharoVM, as it is already the case for similar code on windows:
https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/a4a08f98c17b23ad54b5e361ffc0280e2ea8e0c3/platforms/win32/vm/sqWin32Window.c#L1308

Though, on windows, only the utf32 field (event at: 6) is changed, while on linux charCode field (event at: 3) is also changed.

I do not see equivalent code on OSX...

However, I suggest deeper change, as in this branch:
https://github.com/OpenSmalltalk/opensmalltalk-vm/tree/Nuke-MacRoman

We should have charCode transformed into a platform independent keyCode, hence not being an ASCII control character, but rather a letter in case of Ctrl+a. (X11 KeySym and windows Virtual Key codes already match ASCII for keys representing ASCII characters).

Then the utf32 can eventually be the ASCII control character or not, whatever we want, we have to decide...

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.