RE: [External] : Re: PROPOSAL: Repurpose one key and reserve it for third-party packages

[Drew Adams]

> >> That's not the proposal, that's the way you look at the proposal.
> >> The proposal is to free one or two keys,
> >
> > You clearly said _one_ key, many times.  Glad to hear now that it's
> > two keys (or at least "1 or 2").
> >
> >> and to reserve them for third-party libraries.  Freeing one or two
> >> keys is (would be) an effort from the viewpoint of Emacs,
> >
> > Not if they're currently not bound by default.
> 
> I wonder: did you actually read the proposal?

Yes.  There's no effort needed if all keys not
currently bound are explicitly freed from use
for default Emacs key bindings.  A fortiori,
for just one or two of them.

Of _them_ - the unbound keys.

Of course if keys that are currently bound by
default are to be freed up then some adjustment
would need to be made.  But no effort is needed
for keys not yet bound - zero, beyond documenting
the fact.

By proposing to free up keys already bound, you
create more effort than is needed (zero), and you
solicit just the kind of back-&-forth objections
that have ensued: this key vs that key: Which
ones should be freed for 3rd-party code?  And
what if we switched this and that?  Or we did
this instead?  Or...?

The simple answer, as a starting point, is _none_
of those keys.  Just free up keys that are not
yet taken, just say that Emacs won't take them.

Additional discussion about possibly freeing up
more keys, which are currently taken, is also
welcome, but it should be separate from staking
out, now, the currently unbound keys as reserved
for 3rd parties.

Additional discussion about possibly refactoring
Emacs key bindings is also welcome.  And there
too I've participated.  There are repeatable keys
whose bindings are currently wasted.  There are
keys whose commands are not so useful or not so
commonly used.  There are keys that would be
better off used as prefix keys.  All of that is
ripe terrain for making keys more useful and
more available.

But all of that entails arguing about _changing_
existing keys, which as you well know is iffy,
risky territory.

My proposal is to separate any and all such
possible default key-binding _changes_ from the
simple act of declaring the keys so far unbound
by default to be reserved for 3rd-party code.

No default keys to relearn or fight over.  Just
a declaration of a moratorium on using up the
remaining virgin keyspace territory.

> >> Your proposal, "to reserve _ALL_ keys currently
> >> not bound by default", has I fear no chance
> >> whatsoever to be adopted.
> >
> > It certainly has no chance if it's not even
> > proposed.  And your immediate subsequent
> > pull-back proposal hasn't helped.
> 
> I'm sorry to read you've seen it as a pull back.
> What I saw was that your request was being ignored,
> and I tried to help with something more constructive.

I would welcome any such support, if that really
is your intention.

It took decades just to get `transient-mark-mode'
turned on by default.  Same thing for `font-lock-mode'.

I have no illusions about how difficult change is.
But there's no failing like not being willing to
propose something just because it looks hard to
get passed.  There's no failing like giving up
without trying.