From: Stefan Kangas <stefan@marxist.se>
To: "Karl O. Pinc" <kop@meme.com>
Cc: 3540@debbugs.gnu.org
Subject: bug#3540: Please reserve a ctrl-key combination for interoperability
Date: Sun, 6 Oct 2019 06:56:16 +0200 [thread overview]
Message-ID: <CADwFkmmRdrrFnV+vtO05gnZ-6UQw1_UovFBEpm-dcR3+3gVL+w@mail.gmail.com> (raw)
In-Reply-To: <1244771200l.4854l.2l@mofo>
"Karl O. Pinc" <kop@meme.com> writes:
> 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.
This wishlist request is now 10 years old. If I understand it
correctly, it is asking for a mandate to never use a particular Ctrl-key
combination (within Emacs core, I assume), in order that people could
then use that key within screen.
I think this is not the best way to go about it. Users of screen or
tmux or whatever could easily just rebind whatever key they find
conflicts with their keybinding for screen or tmux commands.
Since this hasn't garnered support from more than one other user in the
last 10 years, I'm therefore proposing to close this as wontfix. If
anyone disagrees with that, please protest now, or I'll do that in a
couple of weeks.
Best regards,
Stefan Kangas
next prev parent reply other threads:[~2019-10-06 4:56 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-12 1:46 bug#3540: Please reserve a ctrl-key combination for interoperability Karl O. Pinc
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 ` Stefan Kangas [this message]
2019-10-06 7:04 ` bug#3540: Please reserve a ctrl-key combination for interoperability 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=CADwFkmmRdrrFnV+vtO05gnZ-6UQw1_UovFBEpm-dcR3+3gVL+w@mail.gmail.com \
--to=stefan@marxist.se \
--cc=3540@debbugs.gnu.org \
--cc=kop@meme.com \
/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).