From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Francis Belliveau 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: 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 ) 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 ) 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 ) 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 ) 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 ) 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "help-gnu-emacs" Xref: news.gmane.org gmane.emacs.help:120849 Archived-At: > On Jun 7, 2019, at 20:31, =C3=93scar Fuentes wrote: >=20 > Francis Belliveau 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