emacs-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#3540: closed (Please reserve a ctrl-key combination for interoperabi


From: GNU bug Tracking System
Subject: bug#3540: closed (Please reserve a ctrl-key combination for interoperability)
Date: Sun, 17 Nov 2019 20:42:02 +0000

Your message dated Sun, 17 Nov 2019 21:41:17 +0100
with message-id <address@hidden>
and subject line Re: bug#3540: Please reserve a ctrl-key combination for 
interoperability
has caused the debbugs.gnu.org bug report #3540,
regarding Please reserve a ctrl-key combination for interoperability
to be marked as done.

(If you believe you have received this mail in error, please contact
address@hidden.)


-- 
3540: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3540
GNU Bug Tracking System
Contact address@hidden with problems
--- Begin Message --- Subject: Please reserve a ctrl-key combination for interoperability Date: Thu, 11 Jun 2009 20:46:40 -0500
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 <address@hidden>
Free Software:  "You don't pay back, you pay forward."
                 -- Robert A. Heinlein



--- End Message ---
--- Begin Message --- Subject: Re: bug#3540: Please reserve a ctrl-key combination for interoperability Date: Sun, 17 Nov 2019 21:41:17 +0100 User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)
Stefan Kangas <address@hidden> writes:

> Marcin Borkowski <address@hidden> writes:
>
>> Psychologically, many people hesitate to rebind default keys for various
>> reasons.  While it is unreasonable for the manual to suggest binding
>> particular keys to particular commands, I would find it very reasonable
>> to encourage users to customize Emacs, including rebinding keys - also
>> the defaults.
>
> To my mind, the manual already covers what you discuss above.  The
> "Intro" section says:
>
>    “Customizable” means that you can easily alter the behavior of Emacs
> commands in simple ways.  For instance, if you use a programming
> language in which comments start with ‘<**’ and end with ‘**>’, you can
> tell the Emacs comment manipulation commands to use those strings (*note
> Comments::).  To take another example, you can rebind the basic cursor
> motion commands (up, down, left and right) to any keys on the keyboard
> that you find comfortable.  *Note Customization::.
>
> That said, we can of course always do better.  I believe it would be
> easier to discuss a more concrete proposal.  Would anyone be willing
> to propose a patch?

Since no one has proposed any concrete changes within 5 weeks, I'll go
ahead and close this bug.  As I write above, we already highlight the
possibility to change key bindings in the "Intro" section of the
manual.  There also didn't seem to be any big enthusiasm for reserving
any new key bindings either.

If anyone disagrees with that, please reopen the bug.

Best regards,
Stefan Kangas


--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]