unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Marcin Borkowski <mbork@mbork.pl>
To: Stefan Kangas <stefan@marxist.se>
Cc: "Karl O. Pinc" <kop@meme.com>, 3540@debbugs.gnu.org
Subject: bug#3540: Please reserve a ctrl-key combination for interoperability
Date: Sun, 06 Oct 2019 09:04:00 +0200	[thread overview]
Message-ID: <87y2xye4nz.fsf@mbork.pl> (raw)
In-Reply-To: <CADwFkmmRdrrFnV+vtO05gnZ-6UQw1_UovFBEpm-dcR3+3gVL+w@mail.gmail.com>


On 2019-10-06, at 06:56, Stefan Kangas <stefan@marxist.se> wrote:

> "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.

As a partial solution, the manual *might* suggest to use C-z for that,
especially that is is bounded to a 99.99% useless command by default
(and using e.g. screen or tmux makes it 100% useless).

Best,

--
Marcin Borkowski
http://mbork.pl





  reply	other threads:[~2019-10-06  7:04 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 ` bug#3540: Please reserve a ctrl-key combination for interoperability Stefan Kangas
2019-10-06  7:04   ` Marcin Borkowski [this message]
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=87y2xye4nz.fsf@mbork.pl \
    --to=mbork@mbork.pl \
    --cc=3540@debbugs.gnu.org \
    --cc=kop@meme.com \
    --cc=stefan@marxist.se \
    /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).