From mboxrd@z Thu Jan  1 00:00:00 1970
Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail
From: Francis Belliveau <f.belliveau@comcast.net>
Newsgroups: gmane.emacs.help
Subject: Re: Ctrl-[ ?
Date: Sat, 8 Jun 2019 17:03:06 -0400
Message-ID: <63F9D100-CD25-445B-8184-93A25DB0FC38@comcast.net>
References: <08AC8151-5911-40FA-8B20-818B839D00AB@traduction-libre.org>
 <86h892nk2g.fsf@zoho.eu>
 <9379C01B-80E3-49DD-B830-46CED773DC2C@traduction-libre.org>
 <83lfydrkde.fsf@gnu.org> <874l51q0s4.fsf@telefonica.net>
 <83ef45rdij.fsf@gnu.org> <87zhmto6fa.fsf@telefonica.net>
 <20190607163017.GA32029@tuxteam.de>
 <96B116FC-8007-4C42-9AE6-585530D0C76E@comcast.net>
 <87muisor2h.fsf@telefonica.net>
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable
Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226";
	logging-data="109396"; mail-complaints-to="usenet@blaine.gmane.org"
To: help-gnu-emacs@gnu.org
Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Sat Jun 08 23:03:40 2019
Return-path: <help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org>
Envelope-to: geh-help-gnu-emacs@m.gmane.org
Original-Received: from lists.gnu.org ([209.51.188.17])
	by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
	(Exim 4.89)
	(envelope-from <help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org>)
	id 1hZiV2-000SMA-4A
	for geh-help-gnu-emacs@m.gmane.org; Sat, 08 Jun 2019 23:03:40 +0200
Original-Received: from localhost ([::1]:60588 helo=lists.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.86_2)
	(envelope-from <help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org>)
	id 1hZiV1-0000SW-1m
	for geh-help-gnu-emacs@m.gmane.org; Sat, 08 Jun 2019 17:03:39 -0400
Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:60365)
 by lists.gnu.org with esmtp (Exim 4.86_2)
 (envelope-from <f.belliveau@comcast.net>) id 1hZiUZ-0000SA-W6
 for help-gnu-emacs@gnu.org; Sat, 08 Jun 2019 17:03:13 -0400
Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <f.belliveau@comcast.net>) id 1hZiUY-0000aI-7j
 for help-gnu-emacs@gnu.org; Sat, 08 Jun 2019 17:03:11 -0400
Original-Received: from resqmta-ch2-10v.sys.comcast.net
 ([2001:558:fe21:29:69:252:207:42]:33204)
 by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32)
 (Exim 4.71) (envelope-from <f.belliveau@comcast.net>)
 id 1hZiUX-0000Yz-SQ
 for help-gnu-emacs@gnu.org; Sat, 08 Jun 2019 17:03:10 -0400
Original-Received: from resomta-ch2-19v.sys.comcast.net ([69.252.207.115])
 by resqmta-ch2-10v.sys.comcast.net with ESMTP
 id Zi3Khzy5G8ekNZiUWh9W0V; Sat, 08 Jun 2019 21:03:08 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net;
 s=20190202a; t=1560027788;
 bh=5XMN46D7FGfoHnbbE+QxDPFp8lKbhctraWjE961jvEA=;
 h=Received:Received:From:Content-Type:Mime-Version:Subject:Date:To:
 Message-Id;
 b=5/Im2i/kQqmc/lwIV8et1920lSq/fdjux9XV7YCAINySOOXT4ALPNSsAO3duV/d55
 Ifcnxh55hzJP2FhIe3v+o/aVJ9/qFarjZsBihaq/H4Pm7SK82UL2FxxnyosQ8+YhAq
 qsLwcyI8LjnS2lgjZmy6Rw5k42SGEnPRGmrTvwUNbxnAU2NzitymF3e4R8f3kaK+mZ
 P4Kb16qlKgl9Nf8OTmLg/2iq6luEiwv7uU+tbM8yRzM0vke6xPBx9DTsxzSEosV+I5
 0KbCiXOaM0lP+LSnIqa/63ZE08ZSIAuPzSqxXkSNYPHKxHPVRXTYwgUsXVguhyUDBd
 xqT6710Yfoz+w==
Original-Received: from [IPv6:2601:190:580:9c44:392f:fc16:2a25:2338]
 ([IPv6:2601:190:580:9c44:392f:fc16:2a25:2338])
 by resomta-ch2-19v.sys.comcast.net with ESMTPSA
 id ZiUUh6G3psHnBZiUWhRwTq; Sat, 08 Jun 2019 21:03:08 +0000
X-Xfinity-VMeta: sc=0;st=legit
In-Reply-To: <87muisor2h.fsf@telefonica.net>
X-Mailer: Apple Mail (2.3445.104.11)
X-detected-operating-system: by eggs.gnu.org: Genre and OS details not
 recognized.
X-Received-From: 2001:558:fe21:29:69:252:207:42
X-BeenThere: help-gnu-emacs@gnu.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Users list for the GNU Emacs text editor <help-gnu-emacs.gnu.org>
List-Unsubscribe: <https://lists.gnu.org/mailman/options/help-gnu-emacs>,
 <mailto:help-gnu-emacs-request@gnu.org?subject=unsubscribe>
List-Archive: <https://lists.gnu.org/archive/html/help-gnu-emacs>
List-Post: <mailto:help-gnu-emacs@gnu.org>
List-Help: <mailto:help-gnu-emacs-request@gnu.org?subject=help>
List-Subscribe: <https://lists.gnu.org/mailman/listinfo/help-gnu-emacs>,
 <mailto:help-gnu-emacs-request@gnu.org?subject=subscribe>
Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org
Original-Sender: "help-gnu-emacs"
 <help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org>
Xref: news.gmane.org gmane.emacs.help:120849
Archived-At: <http://permalink.gmane.org/gmane.emacs.help/120849>


> On Jun 7, 2019, at 20:31, =C3=93scar Fuentes <ofv@wanadoo.es> wrote:
>=20
> Francis Belliveau <f.belliveau@comcast.net> writes:
>=20
>> 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.
>=20
> 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?
>=20

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 =3D Backspace
C-I =3D Tab
C-j =3D Line-Feed
C-m =3D Carriage-Return
C-[ =3D 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-[ =3D Escape, C-i =3D Tab and C-m =3D Enter, Delete =3D Backspace. =20
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. =20
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