On 2014-08-14, 8:36, Mitchell wrote:
> This is not correct. When I press "^V Backspace" in my terminal, I
> get ^? (127). Textadept will interpret it as ASCII 8 ('\b'), while ^H
> will be interpreted as Ctrl+H ('ch'). In my case at least, I can
> distinguish between Backspace and ^H. If BS is mapped to ^H, then
> Textadept will always see 'ch', and not '\b'.
> Is this not desirable? Maybe I "fixed" the wrong thing...
Hi Mitchell. Please let me explain why I think this to be undesirable.
The whole key handling is a bit confusing, therefore I will give some
background information, in case somebody does not know how it works.
If a key is pressed, a scancode is sent to the computer. The scancode
is translated into a keycode, and the keycodes, in turn, are translated
Now the problem is: console applications do not read keysyms like X
applications, they read ASCII sequences. That means a terminal has to
translate every keysym into an ASCII sequence and send this to the
application. Unfortunately, not all terminals are the same -- they use
different ways to encode the keysyms. Accordingly, the ASCII sequences
do not have a fixed meaning. Thus, a console application should NOT
assume a fixed meaning of a given ASCII code. Instead, the application
has to check a terminal database (termcap/terminfo), to find out the
meaning of the ASCII code in the used terminal.
The backspace key is one example for this. Some terminals encode it as
ASCII 127, some as ASCII 8.
With the latest commit, there is a hardcoded assumption that ASCII 8 is
an encoding of Ctrl-H. This is not true for every terminal. For
instance, when a terminal is used that encodes Backspace as ASCII 8, the
backspace key is misinterpreted as Ctrl-h.
In the past, there has been a lot of trouble with the backspace and
delete keys in different terminals and different applications. One can
search the web for "terminal backspace delete" to get an impression. To
avoid such problems, it is crucial to adhere to the standards and
respect the information in the terminal database, instead of hardcoded
mappings, which work on certain systems only.
It is great that Textadept uses libtermkey, because it follows the
terminfo database and is thus compatible with all the terminals
around. Additionally, it enables unequivocal encodings for key +
modifier combinations in terminals with support for the "CSI u" scheme.
To conclude, there is no need to bypass the default libtermkey logic.
It already works as it should. As Niklas found out, the original
problem with Backspace being interpreted as "0" was totally unrelated
to this issue.
-- You are subscribed to code.att.foicica.com. To change subscription settings, send an e-mail to code+help.att.foicica.com. To unsubscribe, send an e-mail to code+unsubscribe.att.foicica.com.Received on Thu 14 Aug 2014 - 14:07:18 EDT
This archive was generated by hypermail 2.2.0 : Fri 15 Aug 2014 - 06:28:14 EDT