From: Stefan Monnier <monnier@iro.umontreal.ca>
To: help-gnu-emacs@gnu.org
Subject: Re: Ctrl-[ ?
Date: Sat, 08 Jun 2019 20:25:36 -0400 [thread overview]
Message-ID: <jwvy32bbp3c.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: 874l4zoiz6.fsf@telefonica.net
> You can monitor those low-level events. The OS usually provides some
> facilities to translate those events to higher level events. I don't
> know at which level Emacs works for GUIs, probably the later. But that's
> irrelevant, because Emacs can detect equally well C-[ as C-t, because
Indeed, as my sample patch shows.
Currently, the core of the "hardcoding" happens in `make_ctrl_char` (in
src/keyboard.c) where we compute an "event with control modifier":
rather than just set to `control` bit on integer events (Emacs
distinguishes events made of "a character plus some modifiers", which
are represented as integers where some bits are used for the modifiers,
from non-character events like `tab`, `next`, `f1, etc which are
represented as symbols instead), we sometimes set the control bit and
sometimes change the char into an "ASCII control char". That's where
"control plus [" is turned into the "ASCII C-[" char which is also
known as ESC (aka code 27).
The core of my patch disables this special case, so instead we always
just set the "control modifier bit" (which is bit 26).
The hard work comes afterwards, because we then need to figure out what
to do with all the parts of Emacs where we previously used code 1 (the
ASCII C-a) instead of code 97 + 2^26 (the combination of the letter `a`
and the control modifier bit).
E.g. part of my patch changes the way we print those. E.g. the current
Emacs code describes both events identically:
(single-key-description (+ 97 (ash 1 26))) => "C-a"
(single-key-description 1) => "C-a"
Which makes debugging these things harder, so my patch changes this (it
changes it by printing "\^a" for the second).
But there are various other related issues. E.g. when we have `?\C-m`
in Elisp code, should the reader consider it as (+ ?m (ash 1 26)) or
as 13? In terms of backward compatibility, there's actually not much
choice: it has to be 13 otherwise lots of code will break (because this
`?\C-m` is really meant to represent the RET character and if we turn
it into (+ ?m (ash 1 26)) we get something that's not even a valid
character (it can't be put inside a string or buffer)). But then we
need a new syntax for "the `m` char combined with the control modifier".
Stefan
next prev parent reply other threads:[~2019-06-09 0:25 UTC|newest]
Thread overview: 63+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-06 4:49 Ctrl-[ ? Jean-Christophe Helary
2019-06-06 12:58 ` Ralph Seichter
2019-06-06 13:42 ` tomas
2019-06-06 14:08 ` Jean-Christophe Helary
2019-06-06 14:25 ` Stefan Monnier
2019-06-06 15:27 ` Jean-Christophe Helary
2019-06-06 18:29 ` Noam Postavsky
2019-06-06 23:08 ` Jean-Christophe Helary
2019-06-06 23:26 ` Noam Postavsky
2019-06-06 23:35 ` Jean-Christophe Helary
2019-06-07 6:24 ` Eli Zaretskii
2019-06-07 11:43 ` Noam Postavsky
2019-06-07 13:16 ` Jean-Christophe Helary
2019-06-07 22:04 ` Stefan Monnier
2019-06-08 6:22 ` Eli Zaretskii
2019-06-08 14:14 ` Stefan Monnier
2019-06-07 3:36 ` Emanuel Berg via help-gnu-emacs
2019-06-07 4:30 ` Jean-Christophe Helary
2019-06-07 4:43 ` Emanuel Berg via help-gnu-emacs
2019-06-07 5:04 ` Jean-Christophe Helary
2019-06-07 6:15 ` Eli Zaretskii
2019-06-07 8:04 ` Óscar Fuentes
2019-06-07 8:44 ` Eli Zaretskii
2019-06-07 13:19 ` Jean-Christophe Helary
2019-06-07 13:54 ` Noam Postavsky
2019-06-07 14:23 ` Jean-Christophe Helary
2019-06-07 15:17 ` Noam Postavsky
2019-06-07 13:45 ` Óscar Fuentes
2019-06-07 14:20 ` Eli Zaretskii
2019-06-07 18:20 ` Óscar Fuentes
2019-06-07 20:16 ` Eli Zaretskii
2019-06-07 16:30 ` tomas
2019-06-08 0:05 ` Francis Belliveau
2019-06-08 0:31 ` Óscar Fuentes
2019-06-08 8:44 ` tomas
2019-06-08 11:48 ` 조성빈 via help-gnu-emacs
2019-06-08 11:56 ` tomas
2019-06-08 13:06 ` Óscar Fuentes
2019-06-08 13:30 ` Eli Zaretskii
2019-06-08 13:54 ` Jean-Christophe Helary
2019-06-08 14:03 ` tomas
2019-06-08 14:22 ` Jean-Christophe Helary
2019-06-08 15:42 ` Eli Zaretskii
2019-06-09 0:52 ` Jean-Christophe Helary
2019-06-09 6:19 ` Eli Zaretskii
2019-06-09 6:51 ` Jean-Christophe Helary
2019-06-08 13:58 ` tomas
2019-06-08 19:40 ` Óscar Fuentes
2019-06-08 20:09 ` Eli Zaretskii
2019-06-08 20:28 ` tomas
2019-06-08 21:03 ` Francis Belliveau
2019-06-08 21:38 ` Óscar Fuentes
2019-06-09 0:25 ` Stefan Monnier [this message]
2019-06-09 1:24 ` Óscar Fuentes
2019-06-18 22:25 ` Stefan Monnier
2019-06-11 23:05 ` Francis Belliveau
2019-06-14 6:51 ` Stefan Monnier
2019-06-14 12:06 ` [offtopic] " Van L
2019-06-14 12:24 ` tomas
2019-06-15 9:12 ` Van L
2019-06-15 9:44 ` tomas
2019-06-15 12:38 ` Van L
2019-06-09 6:37 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=jwvy32bbp3c.fsf-monnier+emacs@gnu.org \
--to=monnier@iro.umontreal.ca \
--cc=help-gnu-emacs@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).