Re: TAB KEY
- Posted by jimcbrown (admin) Nov 16, 2020
- 1094 views
Have you actually tested this though? I no longer have Windoze and can't try it out myself, but based on the implementation I'd expect getting a Control+I with get_key() on that platform to return 1015936.
I just tried this using key.ex on Windows 10 with Euphoria 4.1 64-bit and Tab returns 1015936 (0xF8080) while Ctrl+I returns 9.
Now that seems like a bug to me. Shouldn't the default behavior be reversed?
Actually, memories are a bit dim, but this might have been my influence. I vaguely remember stating to someone (probably Derek or Jeremy over IRC) that we should default to using Ctrl+I (and Ctrl+J et al) as the defaults since keys like Tab/Return/etc might be mapped elsewhere. I might have said it should be done to be cross-platform, citing some termcap/terminfo oddity (where say the Tab key was configured for some other value but Ctrl+I still worked) or looked at xev on the X Windows System, where the Tab key is specified as keycode 23 or keysym 0xff09. (I almost wonder if the choice of 0xF8080 is intended as some kind of pun over 0xff09 - 08 is above 09, and iirc Derek preferred big endian, hence the swap from 08 to 80.)
Also, I've reread the code and realized that it was intended to behave this way. See below,
(EuChar == 9 && vkey != 73) || // TAB key but not CTRL-I
So it doesn't go through the conversion if Ctrl+I was pressed, only for other tabs.
