#487 Switches of upper/lower cases in character events
Ethan has found that src/mouse.c contains a strange if condition at event_keypress function. It is on automatic switches of (lower vs. upper) cases of characters in char events; it can be useful when we do not get that info directly from the event (e.g. when it is with ctrl, it tends to suffer on that).
It contains ((c & 0xff) == 0) that means that it only allows chars that have no 1 bit in lower eight bits. Looking via git blame src/mouse.c revealed that it was done in d51915a2 commit. Then looking into chnages made by that commit: git checkout d51915a2; git reset HEAD^; git diff; reveal that the commit contained this description:
+ * src/mouse.c (event_keypress): MinGW's toupper() masks out high bits + required for special keys. Only call for 8bit characters. Fixes + shift-mousedrag for wxt and windows terminals.
It was clearly meant that 0xff should had been in binary negation. Though it would be readable if it were something like ((c>='a') && (c<='z')), since other ASCII characters will not be put to upper cases. It should be either completely commented out, or repaired.
But wait! It had been setting the case according to the Shift key, though when caps lock is set, Shift key changes the case the other way. Thus the original code expected that caps lock is not set. That is not exactly nice. One can say that either to detect caps lock state or let it completely off.
Finding out the state of caps lock seems to be platform dependent, with some code examples at:
https://www.qtcentre.org/threads/30180-how-to-determine-if-CapsLock-is-on-crossplatform
https://stackoverflow.com/questions/9830905/qt-4-7-4-is-there-a-way-to-find-out-the-status-of-caps-lock
https://stackoverflow.com/questions/2968336/qt-password-field-warn-about-caps-lock
https://stackoverflow.com/questions/9009775/using-getkeystatevk-capital-1-in-linux
Though it all is mostly the same, and just win32 and x11.