Re: Ctrl-[ ?

[Francis Belliveau <f.belliveau@comcast.net>]

> 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