GNU bug report logs - #3540
Please reserve a ctrl-key combination for interoperability

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 3540 in the body.
You can then email your comments to 3540 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: "Karl O. Pinc" <kop <at> meme.com>
To: bug-gnu-emacs <at> gnu.org
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 <kop <at> meme.com>
Free Software:  "You don't pay back, you pay forward."
                 -- Robert A. Heinlein

Message #10 received at 3540 <at> debbugs.gnu.org (full text, mbox):

From: Arne Babenhauserheide <arne_bab <at> yahoo.de>
To: 3540 <at> debbugs.gnu.org
Cc: arne_bab <at> web.de
Subject: reserve a key + inform other gnu package maintainers and mode-authors
Date: Sat, 25 Dec 2010 12:02:30 +0100

I’d love to see an officially reserved key, too (which emacs promises to
keep reserved), ideally a standard letter (which is also readily
available on international keyboards). Any special character (like \)
will prove problematic with international keyboards — and even more with
alternate keyboard layouts.

Naturally the problem with this is that no C-<key> combination is free anymore…

I think I’ll use C-o, because adding newlines behind the point generally
only confuses me when I hit C-o by error, but I assume many people use
it and would be angry to lose the command if it would be made the
default reserved key… 

Another problem with C-o is that C-M-o runs split-current line which
many people might use. 

So selecting a reserved key might take some though - and ideally an
emacs user-survey. 

Best wishes, 
Arne

Message #13 received at 3540 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefan <at> marxist.se>
To: "Karl O. Pinc" <kop <at> meme.com>
Cc: 3540 <at> debbugs.gnu.org
Subject: Re: bug#3540: Please reserve a ctrl-key combination for
 interoperability
Date: Sun, 6 Oct 2019 06:56:16 +0200

"Karl O. Pinc" <kop <at> 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

Message #16 received at 3540 <at> debbugs.gnu.org (full text, mbox):

From: Marcin Borkowski <mbork <at> mbork.pl>
To: Stefan Kangas <stefan <at> marxist.se>
Cc: "Karl O. Pinc" <kop <at> meme.com>, 3540 <at> debbugs.gnu.org
Subject: Re: bug#3540: Please reserve a ctrl-key combination for
 interoperability
Date: Sun, 06 Oct 2019 09:04:00 +0200

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

> "Karl O. Pinc" <kop <at> 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

Message #19 received at 3540 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Marcin Borkowski <mbork <at> mbork.pl>, Stefan Kangas <stefan <at> marxist.se>
Cc: "Karl O. Pinc" <kop <at> meme.com>, 3540 <at> debbugs.gnu.org
Subject: RE: bug#3540: Please reserve a ctrl-key combination for
 interoperability
Date: Sun, 6 Oct 2019 09:10:59 -0700 (PDT)

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

No, please don't do that.  IMO:

`C-z' is better used by users and libraries as a
_prefix key_ (by users who are willing to forego
the default binding).

The manual should not suggest that users bind any
particular keys.  It's OK for a 3rd-party library
to suggest key bindings.  It's not good for Emacs
itself to do that.

3rd-party libraries are opt-in by users.  Using
one is like adding its feature/code to your init
file - it's a user choice.

The same isn't true of much of the code distributed
by Emacs.  And even when a distributed library (e.g.
`dired-x.el') is opt-in, Emacs should not suggest
bindings for its commands.  "Suggestion" by Emacs
is sometimes mistakenly taken by users as a "rule"
or a convention.

There's no good reason for Emacs to suggest that
users use `C-z' for anything particular.

Message #22 received at 3540 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Marcin Borkowski <mbork <at> mbork.pl>
Cc: kop <at> meme.com, stefan <at> marxist.se, 3540 <at> debbugs.gnu.org
Subject: Re: bug#3540: Please reserve a ctrl-key combination for
 interoperability
Date: Sun, 06 Oct 2019 20:38:23 +0300

> From: Marcin Borkowski <mbork <at> mbork.pl>
> Date: Sun, 06 Oct 2019 09:04:00 +0200
> Cc: "Karl O. Pinc" <kop <at> meme.com>, 3540 <at> debbugs.gnu.org
> 
> > 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,

I'd suggest C-F5 (or C-Fn for any n > 4).

Message #25 received at 3540 <at> debbugs.gnu.org (full text, mbox):

From: Marcin Borkowski <mbork <at> mbork.pl>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: "Karl O. Pinc" <kop <at> meme.com>, Stefan Kangas <stefan <at> marxist.se>,
 3540 <at> debbugs.gnu.org
Subject: Re: bug#3540: Please reserve a ctrl-key combination for
 interoperability
Date: Sun, 06 Oct 2019 21:39:50 +0200

On 2019-10-06, at 18:10, Drew Adams <drew.adams <at> oracle.com> wrote:

>> 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).
>
> No, please don't do that.  IMO:
>
> `C-z' is better used by users and libraries as a
> _prefix key_ (by users who are willing to forego
> the default binding).

Actually, that's what I do in my config.  (Is there anyone who actually
wants C-z's default binding???)

> The manual should not suggest that users bind any
> particular keys.  It's OK for a 3rd-party library
> to suggest key bindings.  It's not good for Emacs
> itself to do that.

I'm not sure I agree.  I'd welcome a list of bindings like C-z or M-o
which do nothing useful by default.  (In fact, I compiled such a list
myself - http://mbork.pl/2019-03-18_Free_Emacs_key_bindings - but I'm
not very happy with it.)

> 3rd-party libraries are opt-in by users.  Using
> one is like adding its feature/code to your init
> file - it's a user choice.
>
> The same isn't true of much of the code distributed
> by Emacs.  And even when a distributed library (e.g.
> `dired-x.el') is opt-in, Emacs should not suggest
> bindings for its commands.  "Suggestion" by Emacs
> is sometimes mistakenly taken by users as a "rule"
> or a convention.

That's why it should be made clear that it's a suggestion, like:

"Many users find some commands not useful for them at all.  They might
want to rebind their keys to ones that they use frequently."

> There's no good reason for Emacs to suggest that
> users use `C-z' for anything particular.

On the contrary, there is: the meaning of C-z is "I want to leave Emacs
for a moment and be able to come back".  If you use screen or tmux, you
express the same wish by pressing a combo starting with the prefix key.

Of course, I'm not insisting at all - just suggesting.

Best,

--
Marcin Borkowski
http://mbork.pl

Message #28 received at 3540 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Marcin Borkowski <mbork <at> mbork.pl>
Cc: "Karl O. Pinc" <kop <at> meme.com>, Stefan Kangas <stefan <at> marxist.se>,
 3540 <at> debbugs.gnu.org
Subject: RE: bug#3540: Please reserve a ctrl-key combination for
 interoperability
Date: Sun, 6 Oct 2019 14:29:15 -0700 (PDT)

> Actually, that's what I do in my config.  (Is there anyone who actually
> wants C-z's default binding???)

Dunno.  But I use something very close to it (for GUI).
It has the same behavior as the default command, unless
you use a prefix arg:

(defun iconify/show-frame (&optional all-action)
  "Iconify selected frame if now shown.  Show it if now iconified.
A non-negative prefix arg iconifies all shown frames.
A negative prefix arg deiconifies all iconified frames."
  (interactive "P")
  (cond ((not all-action)
         (when rename-frame-when-iconify-flag
           (rename-non-minibuffer-frame))
         (iconify-or-deiconify-frame))
        ((natnump (prefix-numeric-value all-action))
         (iconify-everything))
        (t (deiconify-everything)))) ; <== Emacs default

But I'm not arguing to keep the default `C-z' binding.
I'm really arguing against wasting `C-z' on something
else, by default.

Someday we'll come across a really important new feature
that really deserves `C-z' (e.g. as a prefix key).  Keys
shouldn't be bound by default lightly.  Once a key is
bound by default it becomes harder to later remove or
replace its binding.

`C-z' is a wonderful key for general things, including
use as a prefix key.  (And if not a prefix key then at
least for a repeatable command.)  And it's as easy to
reach as `C-x' on most keyboards.

If ever there was a key that I don't think should be
bound by default willy nilly (aka wasted, in my view),
it's `C-z'.

> > The manual should not suggest that users bind any
> > particular keys.  It's OK for a 3rd-party library
> > to suggest key bindings.  It's not good for Emacs
> > itself to do that.
> 
> I'm not sure I agree.  I'd welcome a list of bindings like C-z or M-o
> which do nothing useful by default.  (In fact, I compiled such a list
> myself - https://urldefense.proofpoint.com/v2/url?u=http-3A__mbork.pl_2019-
> 2D03-2D18-5FFree-5FEmacs-5Fkey-
> 5Fbindings&d=DwIBAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=kI3P6ljGv
> 6CTHIKju0jqInF6AOwMCYRDQUmqX22rJ98&m=vtPmjCas97xufIKnzS06ZEh04AKsMp8iJj-
> 9W7kHURQ&s=zXD57trzqr01K4n0EBvwEqWYU6PCjR6gahEDtLcmms8&e=  - but I'm
> not very happy with it.)

One person's not-very-useful is another's useful.

And certainly the manual shouldn't suggest that users
bind some key that has a default binding because that
binding isn't very useful.

If Emacs really thinks some default binding isn't
very useful then it shouldn't bind it by default.

> > 3rd-party libraries are opt-in by users.  Using
> > one is like adding its feature/code to your init
> > file - it's a user choice.
> >
> > The same isn't true of much of the code distributed
> > by Emacs.  And even when a distributed library (e.g.
> > `dired-x.el') is opt-in, Emacs should not suggest
> > bindings for its commands.  "Suggestion" by Emacs
> > is sometimes mistakenly taken by users as a "rule"
> > or a convention.
> 
> That's why it should be made clear that it's a suggestion, like:
> 
> "Many users find some commands not useful for them at all.  They might
> want to rebind their keys to ones that they use frequently."

That's not helpful, IMO.  Anyone can know that and
do that, without Emacs suggesting to bind specific
keys. And what one user finds not useful another one
finds useful.

(Why does "Many users..." remind me of DJT's "Many
people are saying..."? ;-))

But sure, many users find some things not useful for
them.  Many users aren't even aware of much of Emacs.
Most users, me included, use only a tiny bit of what
Emacs offers.

Users differ.  Use cases differ.  There are many ways
to use Emacs.

Any user who finds some key that is bound by default
not to be useful can rebind it.  That's not specific
to any particular key.  The doc should not be trying
to find and inform about keys that "many users" find
not so useful.

> > There's no good reason for Emacs to suggest that
> > users use `C-z' for anything particular.
> 
> On the contrary, there is: the meaning of C-z is "I want to leave Emacs
> for a moment and be able to come back".

Not in GUI Emacs, it's not, unless you consider
iconifying to be "leaving Emacs".

Message #31 received at 3540 <at> debbugs.gnu.org (full text, mbox):

From: Marcin Borkowski <mbork <at> mbork.pl>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: "Karl O. Pinc" <kop <at> meme.com>, Stefan Kangas <stefan <at> marxist.se>,
 3540 <at> debbugs.gnu.org
Subject: Re: bug#3540: Please reserve a ctrl-key combination for
 interoperability
Date: Wed, 09 Oct 2019 20:33:03 +0200

On 2019-10-06, at 23:29, Drew Adams <drew.adams <at> oracle.com> wrote:

>> Actually, that's what I do in my config.  (Is there anyone who actually
>> wants C-z's default binding???)
>
> Dunno.  But I use something very close to it (for GUI).
> It has the same behavior as the default command, unless
> you use a prefix arg:
>
> (defun iconify/show-frame (&optional all-action)
>   "Iconify selected frame if now shown.  Show it if now iconified.
> A non-negative prefix arg iconifies all shown frames.
> A negative prefix arg deiconifies all iconified frames."
>   (interactive "P")
>   (cond ((not all-action)
>          (when rename-frame-when-iconify-flag
>            (rename-non-minibuffer-frame))
>          (iconify-or-deiconify-frame))
>         ((natnump (prefix-numeric-value all-action))
>          (iconify-everything))
>         (t (deiconify-everything)))) ; <== Emacs default
>
> But I'm not arguing to keep the default `C-z' binding.
> I'm really arguing against wasting `C-z' on something
> else, by default.
>
> Someday we'll come across a really important new feature
> that really deserves `C-z' (e.g. as a prefix key).  Keys
> shouldn't be bound by default lightly.  Once a key is
> bound by default it becomes harder to later remove or
> replace its binding.
>
> `C-z' is a wonderful key for general things, including
> use as a prefix key.  (And if not a prefix key then at
> least for a repeatable command.)  And it's as easy to
> reach as `C-x' on most keyboards.
>
> If ever there was a key that I don't think should be
> bound by default willy nilly (aka wasted, in my view),
> it's `C-z'.

I agree.

>> > The manual should not suggest that users bind any
>> > particular keys.  It's OK for a 3rd-party library
>> > to suggest key bindings.  It's not good for Emacs
>> > itself to do that.
>> 
>> I'm not sure I agree.  I'd welcome a list of bindings like C-z or M-o
>> which do nothing useful by default.  (In fact, I compiled such a list
>> myself - https://urldefense.proofpoint.com/v2/url?u=http-3A__mbork.pl_2019-
>> 2D03-2D18-5FFree-5FEmacs-5Fkey-
>> 5Fbindings&d=DwIBAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=kI3P6ljGv
>> 6CTHIKju0jqInF6AOwMCYRDQUmqX22rJ98&m=vtPmjCas97xufIKnzS06ZEh04AKsMp8iJj-
>> 9W7kHURQ&s=zXD57trzqr01K4n0EBvwEqWYU6PCjR6gahEDtLcmms8&e=  - but I'm
>> not very happy with it.)
>
> One person's not-very-useful is another's useful.

Of course.

> And certainly the manual shouldn't suggest that users
> bind some key that has a default binding because that
> binding isn't very useful.
>
> If Emacs really thinks some default binding isn't
> very useful then it shouldn't bind it by default.

Here I don't agree.

Logically, you are of course right.

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.

After all, customizability is one of Emacs' greatest strengths.  It
should be natural for the manual to encourage the users to take
advantage of it.

>> > 3rd-party libraries are opt-in by users.  Using
>> > one is like adding its feature/code to your init
>> > file - it's a user choice.
>> >
>> > The same isn't true of much of the code distributed
>> > by Emacs.  And even when a distributed library (e.g.
>> > `dired-x.el') is opt-in, Emacs should not suggest
>> > bindings for its commands.  "Suggestion" by Emacs
>> > is sometimes mistakenly taken by users as a "rule"
>> > or a convention.
>> 
>> That's why it should be made clear that it's a suggestion, like:
>> 
>> "Many users find some commands not useful for them at all.  They might
>> want to rebind their keys to ones that they use frequently."
>
> That's not helpful, IMO.  Anyone can know that and
> do that, without Emacs suggesting to bind specific
> keys. And what one user finds not useful another one
> finds useful.

Again: logically, you're correct.  But there is a huge gap between
"knowing" and "doing".  And some people (me included) could find such an
ecouragement helpful.

> (Why does "Many users..." remind me of DJT's "Many
> people are saying..."? ;-))

I have no idea who or what DJT is.  DuckDuckGo mentioned one of the
better American presidents, is that what you meant?

> But sure, many users find some things not useful for
> them.  Many users aren't even aware of much of Emacs.
> Most users, me included, use only a tiny bit of what
> Emacs offers.
>
> Users differ.  Use cases differ.  There are many ways
> to use Emacs.
>
> Any user who finds some key that is bound by default
> not to be useful can rebind it.  That's not specific
> to any particular key.  The doc should not be trying
> to find and inform about keys that "many users" find
> not so useful.
>
>> > There's no good reason for Emacs to suggest that
>> > users use `C-z' for anything particular.
>> 
>> On the contrary, there is: the meaning of C-z is "I want to leave Emacs
>> for a moment and be able to come back".
>
> Not in GUI Emacs, it's not, unless you consider
> iconifying to be "leaving Emacs".

While I do not consider iconifying to be "leaving Emacs", I think it can
be described as "leaving Emacs for a moment", which is a very different
concept.

Again: I don't think this is so important to waste so much time
discussing.  I can live without any change in that department.  But
I guess that some encouragement to rebind keys in the manual could be
beneficial.

Best,

-- 
Marcin Borkowski
http://mbork.pl

Message #34 received at 3540 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefan <at> marxist.se>
To: Marcin Borkowski <mbork <at> mbork.pl>
Cc: "Karl O. Pinc" <kop <at> meme.com>, 3540 <at> debbugs.gnu.org,
 Drew Adams <drew.adams <at> oracle.com>
Subject: Re: bug#3540: Please reserve a ctrl-key combination for
 interoperability
Date: Thu, 10 Oct 2019 13:04:10 +0200

Marcin Borkowski <mbork <at> mbork.pl> 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?

Best regards,
Stefan Kangas

Message #39 received at 3540-done <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefan <at> marxist.se>
To: Marcin Borkowski <mbork <at> mbork.pl>
Cc: 3540-done <at> debbugs.gnu.org, "Karl O. Pinc" <kop <at> meme.com>,
 Drew Adams <drew.adams <at> oracle.com>
Subject: Re: bug#3540: Please reserve a ctrl-key combination for
 interoperability
Date: Sun, 17 Nov 2019 21:41:17 +0100

Stefan Kangas <stefan <at> marxist.se> writes:

> Marcin Borkowski <mbork <at> mbork.pl> 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

Message #42 received at 3540 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefan <at> marxist.se>
To: Marcin Borkowski <mbork <at> mbork.pl>
Cc: "Karl O. Pinc" <kop <at> meme.com>, Drew Adams <drew.adams <at> oracle.com>,
 3540 <at> debbugs.gnu.org
Subject: Re: bug#3540: Please reserve a ctrl-key combination for
 interoperability
Date: Sun, 24 Nov 2019 00:37:50 +0100

tags 3540 + notabug wontfix
close 3540
thanks

Stefan Kangas <stefan <at> marxist.se> writes:

> Marcin Borkowski <mbork <at> mbork.pl> 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::.

No further comments within 5 weeks, and it doesn't seem like there's
anything to do here.  I'm therefore closing this bug.

If anyone disagrees with that, feel free to reopen the bug report, or
just reply back to state your opinion.  If anyone does that, may I
suggest to then also include a suggestion for what to do.

Best regards,
Stefan Kangas

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.