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
next prev parent 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).