Emacs default key bindings [was: Opening Up More Keymaps Re: Standardizing more key bindings?]

Emacs default key bindings [was: Opening Up More Keymaps Re: Standardizing more key bindings?]

[Drew Adams]

> Perhaps it's time we opened up some additional keymaps...

Stayed out of this thread so far, hoping it would die
a healthy natural death. ;-)  But here are my general
thoughts on the matter, FWIW.
___


1. Keyboard keys are scarce.  Many are already "taken"
by default by Emacs.  (Yes, of course, users and
libraries can always _override_ any default bindings.)

Some of the keys Emacs has "taken" could fruitfully
be revisited.

Some are easily repeatable keys that are bound by
default to nonrepeatable commands, i.e., commands
that it makes no sense to hold the key down to repeat.

Some are particularly easy/quick to type, and are
bound to commands that might not be used that often.

Some were perhaps taken only because a key seemed to
be free at the time (often long ago), regardless of
how much a default binding was needed.  (Recently F2
has come up, as having been sacrificed for the
relatively unused/not-so-useful `2C-*' commands.)

Any such keys could be looked at as keys we might
possibly want to "open up".

(And no, I'm not saying that there aren't other
things to take into account when deciding on a
default key binding.  Ease/speed of finger access,
for example.)


2. But what do we mean by "open up" or "free" a
default key binding?  _I_ mean free it for use by
users and 3rd-party libraries.  Have Emacs give it
up - let it go.

I don't mean for Emacs to just bind it to something
different by default.  That's _not_ freeing it up;
that's just rearranging.  Rearranging can be useful
sometimes, but it doesn't help with the problem of
Emacs binding too many keys by default.

Some here feel the pinch as Emacs not having enough
free keys to bind to more commands by default.  I
feel the problem is the opposite: the pinch is on
users and 3rd-party libraries, and Emacs is doing
the pinching.  Some here see a "free" key and want
to bind it by default, sometimes to their shiny
new command.


3. There's been a tendency recently to give Emacs
even more default key bindings.  Two cases come
to mind, both in 2020:

a. `C-x p' was taken by Emacs as a prefix key for
   `project.el' commands.
b. `C-x t' was taken by Emacs as a prefix key for
   `tabbar.el' commands.

Maybe those deserve prefix keys (?).  But you see
the tendency - less and less for users; more taken
by default bindings.

That's 2 excellent prefix keys just removed, in
effect, from the user/3rd-party space.  Poof!

For example, in my code I've used `C-x p' and
`C-x 4 p' as prefix keys for Bookmark+ for over
10 years, but I changed them (`C-x x', `C-x 4 x')
in 2020 because of (a).

(I have 86 key bindings organized onto those two
prefix keys - some on submaps: `C-x x a',
`C-x x b', `C-x x c', `C-x x t', `C-x x t +',...)

And I've used `C-x t' as a suggested prefix key
for library DoReMi for 16 years.  But I'll have to
change that in 2020 because of (b).

I pointed this out here at the time.  Response was,
in effect, "tough tiddlywinks".  OK.

https://lists.gnu.org/archive/html/emacs-devel/2019-12/msg00085.html

The point is that instead of Emacs trying to reserve
_more_ keys as free for its users (without having to
override default bindings), the impetus here has
been to sacrifice ever more keys to default bindings.


4. When Emacs does decide to bind a key by default,
these two general guidelines (at least) should be
considered, IMO.  (This applies to rearranging, as
well as to binding a previously free key.)  

1. Save naturally repeatable keys for commands that
   can be repeated, i.e., commands that it makes
   sense to be able to hold down a key to repeat.

2. Save some keys for prefix keys, as opposed to
   just sacrificing them for a single command.  A
   prefix key gives you a whole keyboard of
   possibilities for a single key.  Think of all
   the mileage we get out of the prefix key `C-x'!
   Of course, adding a prefix key makes a key
   sequence longer, more complex.  Tradeoff.


___________________

That point (#4) and the rest of this message
were part of a post of mine to help-gnu-emacs
on 9/23/2020, on pretty much this same topic:

https://lists.gnu.org/archive/html/help-gnu-emacs/2020-09/msg00273.html

I tend to define lots of keys for features I write,
and put them, by groups, on their own keymaps, and
then put those keymaps on prefix keys.

Even if such a prefix key appears complicated or
slow, the fact of using a separate keymap means
that a user can easily put it on a different,
shorter key, or remap it to a more global keymap.

Now imagine that keys aren't reserved by Emacs this
way - repeatable keys for repeatable commands, and
some keys available to be used as prefix keys.

Imagine if Emacs just predefined `C-x' for a single
command (e.g. `cut').  _Zillions_ of keys bound now
under `C-x' would be sacrificed.

At the very least, when a new key is decided to be
sacrificed by default (vanilla Emacs), it had better
be bound to a repeatable command, not one (such as
`cut') that it makes no sense to repeat.

And even a repeatable key is a sacrifice - consider
if `C-x' were bound to, say, `forward-word'.
Repeatable, yes, but think of all the bindings now
under `C-x' that would be lost.

Keyboard keys are precious - scarce.  Too many have
already been sacrificed to default bindings, IMO.
Sure, any user or library can redefine any keys.
But once blessed as a default vanilla-Emacs key
binding, a key is, for practical purposes, kinda
off limits for a library.

The point is that (1) it's easy to move a keymap
from one prefix key to another, and (2) there need
to be some prefix keys available to move maps to.

Eventually, I imagine (hope) that some simple,
repeatable keys that have been assigned default
Emacs bindings for commands that aren't repeatable,
or that aren't super useful, or that don't really
need a single-key binding, will be recycled and
put to better use: for repeatable commands, as
prefix keys, or just unbound by default and left
available for libraries.

No, I don't have particular suggestions, and no,
it's not urgent.

But consider `M-!', for example.  Sure, `!' is
mnemonic for shell.  But `M-!' is repeatable
(just hold it down), and it makes no sense to
repeat `shell-command'.  There are other default
key bindings like this - essentially wasted wrt
easy repetition.

Some nonrepeatable commands bound to repeatable
keys should be replaced by repeatable versions.
I do that for `C-a' and `C-e', for example, so
they're similar to `C-n' and `C-p' (repeatable).
That kind of change is minimal - it's the least
we can do to make things a little saner.

Take a look at `C-h b', and see which repeatable
keys are bound to nonrepeatable commands.  Not
too many, but there are some.

Even `C-w' is "wasted" on a nonrepeatable command.
Am I suggesting that `C-w' should not be bound by
default to `kill-region'?  Not really.  That's not
urgent, at least.  But hey, keys are limited - the
keyboard's a small planet. ;-)

And `beginning-of-buffer'.  That nonrepeatable
command's bound by default to two repeatable keys,
`M-<' and `C-home'.  Both mnemonic (good).  But...

RE: Emacs default key bindings [was: Opening Up More Keymaps Re: Standardizing more key bindings?]

[arthur miller]

[-- Attachment #1: Type: text/plain, Size: 8740 bytes --]

I usually say shortcuts are a scarce resource in Emacs; but I don't think it should be taken to seriously either. I think that most users when they are experienced enough with Emacs will rebind stuff either because they prefer other then default functionality or because some other setup make more sense for them.

Also in general if it is not enough with shortcuts, users can simply define extra prefixes. For example I do that in my jnit file:

(global-set-key (kbd "C-z") 'C-z-map)
(define-prefix-command 'C-f-map)
(global-set-key (kbd "C-f") 'C-f-map)
(define-prefix-command 'C-t-map)
(global-set-key (kbd "C-t") 'C-t-map)
(global-unset-key (kbd "C-v"))

It is not harder then so and it gives me any of shortcuts to play with.

Maybe the manual should be more explicit and encourage users to go and define their own prefixes and create their shortcuts. It also might be an idea to write a chapter on how to effectively work with Emacs, shortcuts and maybe some similar related stuff so users are more comfortable with exploring their own ideas instead or pre-canned solutions like Emacs defaults or evil/doom/etc.

-------- Originalmeddelande --------
Från: Drew Adams <drew.adams@oracle.com>
Datum: 2020-10-02 20:17 (GMT+01:00)
Till: "T.V Raman" <raman@google.com>, Thibaut Verron <thibaut.verron@gmail.com>
Kopia: emacs-devel <emacs-devel@gnu.org>
Ämne: Emacs default key bindings    [was: Opening Up More Keymaps Re: Standardizing more key bindings?]

> Perhaps it's time we opened up some additional keymaps...

Stayed out of this thread so far, hoping it would die
a healthy natural death. ;-)  But here are my general
thoughts on the matter, FWIW.
___


1. Keyboard keys are scarce.  Many are already "taken"
by default by Emacs.  (Yes, of course, users and
libraries can always _override_ any default bindings.)

Some of the keys Emacs has "taken" could fruitfully
be revisited.

Some are easily repeatable keys that are bound by
default to nonrepeatable commands, i.e., commands
that it makes no sense to hold the key down to repeat.

Some are particularly easy/quick to type, and are
bound to commands that might not be used that often.

Some were perhaps taken only because a key seemed to
be free at the time (often long ago), regardless of
how much a default binding was needed.  (Recently F2
has come up, as having been sacrificed for the
relatively unused/not-so-useful `2C-*' commands.)

Any such keys could be looked at as keys we might
possibly want to "open up".

(And no, I'm not saying that there aren't other
things to take into account when deciding on a
default key binding.  Ease/speed of finger access,
for example.)


2. But what do we mean by "open up" or "free" a
default key binding?  _I_ mean free it for use by
users and 3rd-party libraries.  Have Emacs give it
up - let it go.

I don't mean for Emacs to just bind it to something
different by default.  That's _not_ freeing it up;
that's just rearranging.  Rearranging can be useful
sometimes, but it doesn't help with the problem of
Emacs binding too many keys by default.

Some here feel the pinch as Emacs not having enough
free keys to bind to more commands by default.  I
feel the problem is the opposite: the pinch is on
users and 3rd-party libraries, and Emacs is doing
the pinching.  Some here see a "free" key and want
to bind it by default, sometimes to their shiny
new command.


3. There's been a tendency recently to give Emacs
even more default key bindings.  Two cases come
to mind, both in 2020:

a. `C-x p' was taken by Emacs as a prefix key for
   `project.el' commands.
b. `C-x t' was taken by Emacs as a prefix key for
   `tabbar.el' commands.

Maybe those deserve prefix keys (?).  But you see
the tendency - less and less for users; more taken
by default bindings.

That's 2 excellent prefix keys just removed, in
effect, from the user/3rd-party space.  Poof!

For example, in my code I've used `C-x p' and
`C-x 4 p' as prefix keys for Bookmark+ for over
10 years, but I changed them (`C-x x', `C-x 4 x')
in 2020 because of (a).

(I have 86 key bindings organized onto those two
prefix keys - some on submaps: `C-x x a',
`C-x x b', `C-x x c', `C-x x t', `C-x x t +',...)

And I've used `C-x t' as a suggested prefix key
for library DoReMi for 16 years.  But I'll have to
change that in 2020 because of (b).

I pointed this out here at the time.  Response was,
in effect, "tough tiddlywinks".  OK.

https://lists.gnu.org/archive/html/emacs-devel/2019-12/msg00085.html

The point is that instead of Emacs trying to reserve
_more_ keys as free for its users (without having to
override default bindings), the impetus here has
been to sacrifice ever more keys to default bindings.


4. When Emacs does decide to bind a key by default,
these two general guidelines (at least) should be
considered, IMO.  (This applies to rearranging, as
well as to binding a previously free key.)

1. Save naturally repeatable keys for commands that
   can be repeated, i.e., commands that it makes
   sense to be able to hold down a key to repeat.

2. Save some keys for prefix keys, as opposed to
   just sacrificing them for a single command.  A
   prefix key gives you a whole keyboard of
   possibilities for a single key.  Think of all
   the mileage we get out of the prefix key `C-x'!
   Of course, adding a prefix key makes a key
   sequence longer, more complex.  Tradeoff.


___________________

That point (#4) and the rest of this message
were part of a post of mine to help-gnu-emacs
on 9/23/2020, on pretty much this same topic:

https://lists.gnu.org/archive/html/help-gnu-emacs/2020-09/msg00273.html

I tend to define lots of keys for features I write,
and put them, by groups, on their own keymaps, and
then put those keymaps on prefix keys.

Even if such a prefix key appears complicated or
slow, the fact of using a separate keymap means
that a user can easily put it on a different,
shorter key, or remap it to a more global keymap.

Now imagine that keys aren't reserved by Emacs this
way - repeatable keys for repeatable commands, and
some keys available to be used as prefix keys.

Imagine if Emacs just predefined `C-x' for a single
command (e.g. `cut').  _Zillions_ of keys bound now
under `C-x' would be sacrificed.

At the very least, when a new key is decided to be
sacrificed by default (vanilla Emacs), it had better
be bound to a repeatable command, not one (such as
`cut') that it makes no sense to repeat.

And even a repeatable key is a sacrifice - consider
if `C-x' were bound to, say, `forward-word'.
Repeatable, yes, but think of all the bindings now
under `C-x' that would be lost.

Keyboard keys are precious - scarce.  Too many have
already been sacrificed to default bindings, IMO.
Sure, any user or library can redefine any keys.
But once blessed as a default vanilla-Emacs key
binding, a key is, for practical purposes, kinda
off limits for a library.

The point is that (1) it's easy to move a keymap
from one prefix key to another, and (2) there need
to be some prefix keys available to move maps to.

Eventually, I imagine (hope) that some simple,
repeatable keys that have been assigned default
Emacs bindings for commands that aren't repeatable,
or that aren't super useful, or that don't really
need a single-key binding, will be recycled and
put to better use: for repeatable commands, as
prefix keys, or just unbound by default and left
available for libraries.

No, I don't have particular suggestions, and no,
it's not urgent.

But consider `M-!', for example.  Sure, `!' is
mnemonic for shell.  But `M-!' is repeatable
(just hold it down), and it makes no sense to
repeat `shell-command'.  There are other default
key bindings like this - essentially wasted wrt
easy repetition.

Some nonrepeatable commands bound to repeatable
keys should be replaced by repeatable versions.
I do that for `C-a' and `C-e', for example, so
they're similar to `C-n' and `C-p' (repeatable).
That kind of change is minimal - it's the least
we can do to make things a little saner.

Take a look at `C-h b', and see which repeatable
keys are bound to nonrepeatable commands.  Not
too many, but there are some.

Even `C-w' is "wasted" on a nonrepeatable command.
Am I suggesting that `C-w' should not be bound by
default to `kill-region'?  Not really.  That's not
urgent, at least.  But hey, keys are limited - the
keyboard's a small planet. ;-)

And `beginning-of-buffer'.  That nonrepeatable
command's bound by default to two repeatable keys,
`M-<' and `C-home'.  Both mnemonic (good).  But...


[-- Attachment #2: Type: text/html, Size: 11442 bytes --]

Re: Emacs default key bindings [was: Opening Up More Keymaps Re: Standardizing more key bindings?]

[Philip K.]

Drew Adams <drew.adams@oracle.com> writes:

> 3. There's been a tendency recently to give Emacs
> even more default key bindings.  Two cases come
> to mind, both in 2020:
>
> a. `C-x p' was taken by Emacs as a prefix key for
>    `project.el' commands.
> b. `C-x t' was taken by Emacs as a prefix key for
>    `tabbar.el' commands.
>
> Maybe those deserve prefix keys (?).  But you see
> the tendency - less and less for users; more taken
> by default bindings.
>
> That's 2 excellent prefix keys just removed, in
> effect, from the user/3rd-party space.  Poof!

I get that they were in effect removed from the 3rd-party space, but the
user is still the final arbiter in what is bound or not. Do you really
loose anything, if you rebind C-x p, if you don't use project.el? Same
goes for C-x t if you don't use tabs.

My point is that there seem to be varying degrees of importance to
key-bindings: Rebinding C-c, let alone a self-insert key is far more
disruptive than M-/, C-o, C-x, C-x a, etc. -- it's just difficult to
draw the line.

-- 
	Philip K.

Re: Emacs default key bindings [was: Opening Up More Keymaps Re: Standardizing more key bindings?]

[Ergus]

On Fri, Oct 02, 2020 at 11:14:48AM -0700, Drew Adams wrote:
>> Perhaps it's time we opened up some additional keymaps...

AFAIR:

C-x is reserved for emacs internal use.
C-c for users.

So, external libraries should be ready to move from C-x * in favor of
internal functionalities when needed. That's the deal. I don't think
that many external features are more important than tabs or project
commands in 2020. That's why they are in vanilla... And keeping some
standard behaviors is very appreciated.

It is not that we use more bindings, but that we have new
functionalities all the time and some of them require new binding. While
some of the oned with repeated bindings or less useful ones have to stay
because otherwise long standing users create a storm here. (ex: F2)

In general I agree with your idea about repeatable commands and bindings
administrations... But you know that any change in that area is a bloody
war.

IMO the only possible solution for this (as with all defaults) is that
Eli, Stefan, Lars and some other of the most implied maintainers (and
with a deeper idea the current direction of the project) find an
agreement between them and impose it in a less democratic way. Otherwise
everyone will try to favor his own use cases, preferred tools and
personal libraries...

Otherwise we can make surveys with fix deadlines... but instead of
making happy everyone this will probably make unhappy everyone. We could
make an online form to vote... (like https://feathub.com/)

In general it is better that emacs keep a reasonable standard behavior
in some aspects otherwise it will be useless when working in different
machines.



>
>Stayed out of this thread so far, hoping it would die
>a healthy natural death. ;-)  But here are my general
>thoughts on the matter, FWIW.
>___
>
>
>1. Keyboard keys are scarce.  Many are already "taken"
>by default by Emacs.  (Yes, of course, users and
>libraries can always _override_ any default bindings.)
>
>Some of the keys Emacs has "taken" could fruitfully
>be revisited.
>
>Some are easily repeatable keys that are bound by
>default to nonrepeatable commands, i.e., commands
>that it makes no sense to hold the key down to repeat.
>
>Some are particularly easy/quick to type, and are
>bound to commands that might not be used that often.
>
>Some were perhaps taken only because a key seemed to
>be free at the time (often long ago), regardless of
>how much a default binding was needed.  (Recently F2
>has come up, as having been sacrificed for the
>relatively unused/not-so-useful `2C-*' commands.)
>
>Any such keys could be looked at as keys we might
>possibly want to "open up".
>
>(And no, I'm not saying that there aren't other
>things to take into account when deciding on a
>default key binding.  Ease/speed of finger access,
>for example.)
>
>
>2. But what do we mean by "open up" or "free" a
>default key binding?  _I_ mean free it for use by
>users and 3rd-party libraries.  Have Emacs give it
>up - let it go.
>
>I don't mean for Emacs to just bind it to something
>different by default.  That's _not_ freeing it up;
>that's just rearranging.  Rearranging can be useful
>sometimes, but it doesn't help with the problem of
>Emacs binding too many keys by default.
>
>Some here feel the pinch as Emacs not having enough
>free keys to bind to more commands by default.  I
>feel the problem is the opposite: the pinch is on
>users and 3rd-party libraries, and Emacs is doing
>the pinching.  Some here see a "free" key and want
>to bind it by default, sometimes to their shiny
>new command.
>
>
>3. There's been a tendency recently to give Emacs
>even more default key bindings.  Two cases come
>to mind, both in 2020:
>
>a. `C-x p' was taken by Emacs as a prefix key for
>   `project.el' commands.
>b. `C-x t' was taken by Emacs as a prefix key for
>   `tabbar.el' commands.
>
>Maybe those deserve prefix keys (?).  But you see
>the tendency - less and less for users; more taken
>by default bindings.
>
>That's 2 excellent prefix keys just removed, in
>effect, from the user/3rd-party space.  Poof!
>
>For example, in my code I've used `C-x p' and
>`C-x 4 p' as prefix keys for Bookmark+ for over
>10 years, but I changed them (`C-x x', `C-x 4 x')
>in 2020 because of (a).
>
>(I have 86 key bindings organized onto those two
>prefix keys - some on submaps: `C-x x a',
>`C-x x b', `C-x x c', `C-x x t', `C-x x t +',...)
>
>And I've used `C-x t' as a suggested prefix key
>for library DoReMi for 16 years.  But I'll have to
>change that in 2020 because of (b).
>
>I pointed this out here at the time.  Response was,
>in effect, "tough tiddlywinks".  OK.
>
>https://lists.gnu.org/archive/html/emacs-devel/2019-12/msg00085.html
>
>The point is that instead of Emacs trying to reserve
>_more_ keys as free for its users (without having to
>override default bindings), the impetus here has
>been to sacrifice ever more keys to default bindings.
>
>
>4. When Emacs does decide to bind a key by default,
>these two general guidelines (at least) should be
>considered, IMO.  (This applies to rearranging, as
>well as to binding a previously free key.)
>
>1. Save naturally repeatable keys for commands that
>   can be repeated, i.e., commands that it makes
>   sense to be able to hold down a key to repeat.
>
>2. Save some keys for prefix keys, as opposed to
>   just sacrificing them for a single command.  A
>   prefix key gives you a whole keyboard of
>   possibilities for a single key.  Think of all
>   the mileage we get out of the prefix key `C-x'!
>   Of course, adding a prefix key makes a key
>   sequence longer, more complex.  Tradeoff.
>
>
>___________________
>
>That point (#4) and the rest of this message
>were part of a post of mine to help-gnu-emacs
>on 9/23/2020, on pretty much this same topic:
>
>https://lists.gnu.org/archive/html/help-gnu-emacs/2020-09/msg00273.html
>
>I tend to define lots of keys for features I write,
>and put them, by groups, on their own keymaps, and
>then put those keymaps on prefix keys.
>
>Even if such a prefix key appears complicated or
>slow, the fact of using a separate keymap means
>that a user can easily put it on a different,
>shorter key, or remap it to a more global keymap.
>
>Now imagine that keys aren't reserved by Emacs this
>way - repeatable keys for repeatable commands, and
>some keys available to be used as prefix keys.
>
>Imagine if Emacs just predefined `C-x' for a single
>command (e.g. `cut').  _Zillions_ of keys bound now
>under `C-x' would be sacrificed.
>
>At the very least, when a new key is decided to be
>sacrificed by default (vanilla Emacs), it had better
>be bound to a repeatable command, not one (such as
>`cut') that it makes no sense to repeat.
>
>And even a repeatable key is a sacrifice - consider
>if `C-x' were bound to, say, `forward-word'.
>Repeatable, yes, but think of all the bindings now
>under `C-x' that would be lost.
>
>Keyboard keys are precious - scarce.  Too many have
>already been sacrificed to default bindings, IMO.
>Sure, any user or library can redefine any keys.
>But once blessed as a default vanilla-Emacs key
>binding, a key is, for practical purposes, kinda
>off limits for a library.
>
>The point is that (1) it's easy to move a keymap
>from one prefix key to another, and (2) there need
>to be some prefix keys available to move maps to.
>
>Eventually, I imagine (hope) that some simple,
>repeatable keys that have been assigned default
>Emacs bindings for commands that aren't repeatable,
>or that aren't super useful, or that don't really
>need a single-key binding, will be recycled and
>put to better use: for repeatable commands, as
>prefix keys, or just unbound by default and left
>available for libraries.
>
>No, I don't have particular suggestions, and no,
>it's not urgent.
>
>But consider `M-!', for example.  Sure, `!' is
>mnemonic for shell.  But `M-!' is repeatable
>(just hold it down), and it makes no sense to
>repeat `shell-command'.  There are other default
>key bindings like this - essentially wasted wrt
>easy repetition.
>
>Some nonrepeatable commands bound to repeatable
>keys should be replaced by repeatable versions.
>I do that for `C-a' and `C-e', for example, so
>they're similar to `C-n' and `C-p' (repeatable).
>That kind of change is minimal - it's the least
>we can do to make things a little saner.
>
>Take a look at `C-h b', and see which repeatable
>keys are bound to nonrepeatable commands.  Not
>too many, but there are some.
>
>Even `C-w' is "wasted" on a nonrepeatable command.
>Am I suggesting that `C-w' should not be bound by
>default to `kill-region'?  Not really.  That's not
>urgent, at least.  But hey, keys are limited - the
>keyboard's a small planet. ;-)
>
>And `beginning-of-buffer'.  That nonrepeatable
>command's bound by default to two repeatable keys,
>`M-<' and `C-home'.  Both mnemonic (good).  But...
>

RE: Emacs default key bindings [was: Opening Up More Keymaps Re: Standardizing more key bindings?]

[Drew Adams]

> > 3. There's been a tendency recently to give Emacs
> > even more default key bindings.  Two cases come
> > to mind, both in 2020:
> >
> > a. `C-x p' was taken by Emacs as a prefix key for
> >    `project.el' commands.
> > b. `C-x t' was taken by Emacs as a prefix key for
> >    `tabbar.el' commands.
> >
> > Maybe those deserve prefix keys (?).  But you see
> > the tendency - less and less for users; more taken
> > by default bindings.
> >
> > That's 2 excellent prefix keys just removed,
> > in effect, from the user/3rd-party space.  Poof!
    ^^^^^^^^^
> 
> I get that they were in effect removed from the 3rd-party space, but the
> user is still the final arbiter in what is bound or not. Do you really
> loose anything, if you rebind C-x p, if you don't use project.el? Same
> goes for C-x t if you don't use tabs.

As I said:

  Sure, any user or library can redefine any keys.

  But once blessed as a default vanilla-Emacs key
  binding, a key is, for practical purposes,
                     ^^^^^^^^^^^^^^^^^^^^^^
  kinda off limits for a library.

It's about what's practical.  And it's about 3rd-party
libraries also, not just individual user customizations.

And who says that a user won't use project.el?  I left
the question open as to whether it needs a prefix key
defined by default.  But suppose it does.  Does it need
to be at the top level of `C-x'?

Scarcity means we should perhaps start thinking of
putting some things on lower levels under `C-x'
(assuming they need default bindings).  We already have
some prefix keys under `C-x': `8' (and several prefix
keys under `C-x 8'), `RET' (`C-m'), `ESC' (for `C-M-'),
`a', `a i', `b', `n', `r', `r ESC', `t', `v M', `@'.

The post I linked to starts by saying that we would do
well to split `C-x r', for example, as it's got a
mixture of stuff on it.

We could do that by having prefix keys under `C-x r'.
My suggestion was to move the bookmark stuff from
`C-x r' to `C-x p', but there are other ways to clean
up `C-x r' from being the congeries that it is now
(rectangle, register, and bookmark, so far).

> My point is that there seem to be varying degrees of
> importance to key-bindings 

I believe I suggested the same thing.  There are several
things to consider when binding a key, including doing
so as a default for Emacs.  Keys are by no means equal
in their abilities, mnemonic suggestions, ease of use,
or other "importance".

RE: Emacs default key bindings [was: Opening Up More Keymaps Re: Standardizing more key bindings?]

[Drew Adams]

> C-x is reserved for emacs internal use.

No, not at all.

> C-c for users.

No.  `C-c' followed by a letter is reserved for users.

Please see node Key Binding Conventions of the Elisp
manual.  Lots of good information there.

https://www.gnu.org/software/emacs/manual/html_node/elisp/Key-Binding-Conventions.html

Re: Emacs default key bindings [was: Opening Up More Keymaps Re: Standardizing more key bindings?]

[Philip K.]

Ergus <spacibba@aol.com> writes:

> On Fri, Oct 02, 2020 at 11:14:48AM -0700, Drew Adams wrote:
>>> Perhaps it's time we opened up some additional keymaps...
>
> AFAIR:
>
> C-x is reserved for emacs internal use.
> C-c for users.

According to "(elisp) Key Binding Conventions":

> Sequences consisting of ‘C-c’ followed by a control character or a
> digit are reserved for major modes.

(not the exceptions listed in the info node)

while C-x is a lot safer for users. It would be very unusual for a major
mode to rebind "C-x ...", which is why I bind most of my local functions
to that map. On the other hand, something like C-c C-... will often be
shadowed by a major mode minor mode, hence I don't bother trying.

-- 
	Philip K.

RE: Emacs default key bindings [was: Opening Up More Keymaps Re: Standardizing more key bindings?]

[Drew Adams]

> > C-x is reserved for emacs internal use.
> > C-c for users.

As I said, both of those statements are wrong.

> According to "(elisp) Key Binding Conventions":
> 
> > Sequences consisting of ‘C-c’ followed by a control
> > character or a digit are reserved for major modes.
> 
> (not the exceptions listed in the info node)

And?  What's your point?  `C-c' is _not_ reserved for
users, in general.  `C-c <letter>' is reserved for users.

> while C-x is a lot safer for users. It would be very
> unusual for a major mode to rebind "C-x ...", 

Why do you think so?  There's nothing in the conventions
about `C-x'.

Don't confuse statements about a binding being reserved
for some use with a claim that a binding not listed as
reserved is somehow off limits.  Such a claim would be
improper.

Everything that's not stated in the conventions is OK.
(Even things that are stated in the conventions are only
that: conventional.)  The conventions exist to help us
not get our feet stepped on, by ourselves or others.

> which is why I bind most of my local functions to that map.

You're free to do so.  Nothing wrong with that, whether
you mean as user or as a library writer.

> On the other hand, something like C-c C-... will often be
> shadowed by a major mode [or] minor mode, hence I don't
> bother trying.

`C-c C-<something' is reserved for a major mode.  If
you're writing a major mode, you can use it, following
the convention.  If you're writing a library and the
library binds `C-c C-<something>' in a map other than
for a major mode then that violates the convention.

As a user you can bind any key to anything, including
binding `C-c C-<something'.

The conventions don't cover user bindings, except to
say that `C-c <letter>' are _reserved_ for users.
A user binding `C-c C-<something' (e.g. globally) might
find a major mode overriding that binding.  That's all.