all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
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





  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

* 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 external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.