Re: About get_key() alternative
- Posted by jimcbrown (admin) Oct 19, 2020
- 1014 views
The last thread about TAB KEY, makes me think about.
get_key() has a problem long long time ago. On DOS and Linux allways was a good keyboard support. On Win32 there are problems to support some keystrokes. This was never solved and we simply accept it this way.
Source code from ed.ex at Eu 3.1 simply says that some keys (like Ctrl_Left and Ctrl_Rigth) are not supported on exwc interpreter. Is a very old bug that requires a solution.
Also is not nice that special characters codes are not the same on any OS.
Some people tried to fix it and caused the problem with TAB Key discussed on another thread.
But there is also a solution provided for the new TAB Key problem, that I just mentioned in the other thread, https://openeuphoria.org/forum/m/135135.wc
My proposal is:
1- Left get_key() as is (as allways has been) to keep compatibility with old code. A text oriented function that return mainly printable characters but not full support for special keys.
The view of the dev team back when the fix was put in was that console support and interaction was a vital subsystem of Euphoria on all platforms.
To this end, we saw a difference between getc(0)/gets(0) on one side and get_key()/wait_key() on the other.
getc(0) et all fit the " text oriented function that return mainly printable characters but not full support for special keys" function.
2- Create a new alternative keyboard function that provide better keyboard information.
The view of the dev team back then was that get_key() et all was the function that was the "alternative keyboard function that provide better keyboard information" and since these already existed, there wasn't a need to provide new ones.
The main problem is that I want to receive the text information (including unicode or regional language characters) and the special keys like F1 in with the same function and be sure not confuse them.
get_key() already supports this, just in some cases you'll need to call console:key_codes() to make sure that some keys return the value that you expect (you can force Tab to be 9, and the numeric keypad to return the same values as their non-keypad counterparts, for example).
Check what other languages do. I inspired on QBASIC that return one byte for printable characters and two byte "0+Other" for special keys http://www.petesqbsite.com/phpBB3/viewtopic.php?t=1105. If your qbasic receives a "0" from keyboard you know that the next byte is an special key, not a printable.
We can explote the power of sequences. A keystroke of several keys like Ctrl+Alt+Insert may become a sequence {CTRL, ALT, INS}. So, if your program receives from the keyboard an atom, is a printable character, but if receives a sequence is an special key that your program can process or discart. We can create a simple table of special key values unified the same for any OS, and left the printable characters as presented by the OS and their locale.
Regards
Marco Achury
This is an excellent idea. The current key_codes() implementation requires that replacement key codes be integers, but updating it to support returning a sequence of keys for a special key would actually make it more in-line with the nix world of things (where we can get multi-character escape sequences for certain special keys based on termcap/terminfo settings).
In fact, with your suggestion implemented, we could easily set up the key codes to be the Linux/GNU xterm termcap escape sequences! Same escape codes, multiple platforms.
I'm really liking this idea.
