Re: Ctrl-[ ?

[Francis Belliveau]

> On Jun 7, 2019, at 20:31, Óscar Fuentes <ofv@wanadoo.es> wrote:
> 
> Francis Belliveau <f.belliveau@comcast.net> writes:
> 
>> I think that a lot of you are missing the point that was made early on
>> in the discussion. This mapping of ASCII cntrol characters is a
>> definition made by convention since the day of the Teletype machines.
>> It is how the ASCII character set was defined.
> 
> So what? Why a GUI user should be inconvenienced or prevented to bind
> C-i, C-[, etc. to whatever he pleases the same way he binds any other
> key combination? You can't bind C-[ on a terminal, because there is a
> technical limitation, ok. But why you can't bind it either on a GUI,
> where the technical limitation does not exist?
> 

There are many other emails on this discussion that I would like to respond to. 
 I chose this one because it is most blatantly missing the point that I am 
attempting to make.  I will try to answer all the comments that I can remember. 
 A lot of emails showed up while I was composing what I have below.

What I am trying to say is that the technical limitation does exist in a GUI 
application because the OS puts it there.

First I would like to say that I do not know much about the internals of the 
EMACS source code, but what I believe that Oscar is expressing below is the 
assumption that the EMACS application has direct access to the keyboard key 
bindings.  If that is the case, then something can certainly be done there to 
change how things work, but as was previously mentioned there may be some 
serious, and difficult to predict, side effects.

However, my development experience is that there are some bindings that are at 
the OS interface level and therefore invisible to the application.  It is 
possible that EMACS is using a lower-level keyboard interface that allows it to 
see raw keystrokes, but I would not have implemented things that way because it 
is very implementation dependent.  I have worked on interfacing directly to 
keyboard input and it can get very messy because it depends on the keyboard 
model that the keystrokes come from, and you need to handle every Key-Down and 
Key-Up along with "repeat actions" when keys are held down too long.  Think of 
what happens if you hold down the shift key long enough for the key-repeat to 
begin; the keyboard starts sending "shift-down" events at the "repeat rate" 
mixed in with any other key events that you perform while holding the shift key 
down.  It is far easier to let the OS drivers untangle all that.  Some 
keyboards come with customizable drivers these days that may allow you to remap 
things in a way that will help.

It is my assumption in what I say below that EMACS is trusting the OS to 
perform the keystroke translations for it.  If there is somebody who knows that 
the application source operates differently, I will abdicate to their greater 
knowledge.  But if you are assuming that I am wrong without that in-depth 
knowledge, then you are likely to be disappointed.

Let me begin with the "documentation" that was requested.  I deleted the 
original posting that contained the explanation of ASCII and how it works.  You 
will find reasonable documentation at
https://en.wikipedia.org/wiki/ASCII
There you will find that a few of the ASCII control-codes are mapped to actual 
keys on your keyboard.  I note those below.

Although ASCII is far from the only character set in use today, I believe that 
you will find that most character sets hold ASCII as the base that they are 
built upon.  This is because it is the first standard character set.
Character sets today come in different sizes, but ASCII only requires 7 bits, 
so even an 8-bit key-code can include a "meta" modifier indication.  A 16-bit 
character set can certainly do a lot more.

I believe that the next level of documentation that was requested is "which 
keys provide identical bindings?"  Every application I ever wrote to interface 
with keyboard input has assumed an 8-bit character set and therefore cannot 
tell the difference in the following key-strokes (using EMACS notation):

C-h = Backspace
C-I = Tab
C-j = Line-Feed
C-m = Carriage-Return
C-[ = Escape

Line-Feed and Carriage-Return are holdovers from how typewriters functioned.  
Depending on the OS you may be able to rebind one, but likely not the other, in 
a manner that does not effect the function run when you use your "Enter" or 
"Return" key.  Please note that I speak only of the main keys on the keyboard.  
Your extra "keypad(s)" will generally send escape-sequences, even for the 
"Enter" key that you will find there.

You will also notice that there is no control sequence available for what ASCII 
calls the Delete character and that C-h is mapped to Backspace.  On a QWERTY 
typewriter keyboard the Backspace key it at the upper right-hand corner where 
most of today's keyboards place what they call a Delete key.

When I use C-hk to ask EMACS for help with a keystroke sequence, I find that
C-[ = Escape, C-i = Tab and C-m = Enter, Delete = Backspace.  
I must admit that I am surprised that C-h and Backspace are actually seen 
differently, but the remainder holds up and the keyboards might actually be 
sending a Delete code that EMACS is calling Backspace.  
Furthermore, the "Enter" button is positioned on the keyboard where the 
Carriage-Return button was placed when electric typewriters were created.

So what I believe that many of you are complaining about is the inability to 
separate the actions by specialized keys on your keyboard from the "control 
code" that they actually generate.

What I am saying is that if EMACS cannot tell the difference, then it cannot 
provide you with the ability to bind them differently.  To fix the problem you 
will need to go deeper into things than just a simple key-mapping like what 
happens when you hit C-z.

Fran