From: "Karl O. Pinc" <kop@meme.com>
To: bug-gnu-emacs@gnu.org
Subject: bug#3540: Please reserve a ctrl-key combination for interoperability
Date: Thu, 11 Jun 2009 20:46:40 -0500 [thread overview]
Message-ID: <1244771200l.4854l.2l@mofo> (raw)
Hello,
I want emacs to keep one control key combination unbound
so that emacs can be run inside other programs that
need an escape character to enter a control mode.
Examples of such programs are screen and minicom.
Screen is a full-screen window manager that multiplexes
a physical terminal between several processes
(typically interactive shells). Minicom is a
serial communication program, a terminal emulator.
It is difficult to use emacs inside such programs because
these programs (by default) bind a commonly used emacs control
key sequence as their escape key. Emacs users should be able to
re-configure such programs to use an unbound emacs ctrl keypress.
Sure, each emacs user could chose their own key combination (I used
ctrl-\, but I recently upgraded from emacs 21 and see it's
now bound in emacs 22), but this makes it almost
impossible to, e.g., publish tutorials/recipies on how to
use, say, screen, with emacs. The person following the
tutorial might need the particular emacs feature that
is no longer bound to the standard emacs key combination.
As things stand emacs users have a bar over which they
must jump to use such useful programs as screen; each
user must figure out what emacs keypress they wish
to sacrifice, taking into account the key combinations
used by screen at a time when they are unfamiliar with
screen. At minimum if a control key combination was
reserved the choice would be obvious, at best either
emacs or the screen documentation would describe
what configuration and usage changes were necessary
to allow the two programs to interoperate.
Frankly, Ctrl-\ was perfect because it was not otherwise
bound in either screen or minicom. The choice of a key
that's already bound in these programs means that yet more
reconfiguration of screen/minicom must be done to retain
functionality, the lost functionality must be bound to
a non-standard key. This introduces yet more incompatibility
between emacs users and the rest of the universe.
Thank you for your time.
Karl <kop@meme.com>
Free Software: "You don't pay back, you pay forward."
-- Robert A. Heinlein
next reply other threads:[~2009-06-12 1:46 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-12 1:46 Karl O. Pinc [this message]
2010-12-25 11:02 ` bug#3540: reserve a key + inform other gnu package maintainers and mode-authors Arne Babenhauserheide
2019-10-06 4:56 ` bug#3540: Please reserve a ctrl-key combination for interoperability Stefan Kangas
2019-10-06 7:04 ` Marcin Borkowski
2019-10-06 16:10 ` Drew Adams
2019-10-06 19:39 ` Marcin Borkowski
2019-10-06 21:29 ` Drew Adams
2019-10-09 18:33 ` Marcin Borkowski
2019-10-10 11:04 ` Stefan Kangas
2019-11-17 20:41 ` Stefan Kangas
2019-11-23 23:37 ` Stefan Kangas
2019-10-06 17:38 ` 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=1244771200l.4854l.2l@mofo \
--to=kop@meme.com \
--cc=3540@emacsbugs.donarmstrong.com \
--cc=bug-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.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
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).