RE: [External] : Re: Concern about new binding.

[Drew Adams]

> I'm puzzled.  The proposal frees one complete keymap for libraries such
> as Magit and yours.  With say C-o, Magit could use C-o g and C-o M-g, you
> could use C-o p and C-o / and ..., and so forth, with the guarantee
> that Emacs would never reclaim any key in that map.  That's a lot of room...
> 
> > I favor allowing all keys that are currently allowed for 3rd-party
> > code.  And I favor Emacs itself implementing a moratorium on
> > binding any more keys by default.
> 
> ... but apparently you prefer to continue to use the few remaining keys
> that are not bound by default?  Isn't that contradictory?

How so?  The few remaining keys are more than a single key.

> > To me, that's too limiting for 3rd-party libraries. I'd prefer what I
> > say above.  Emacs itself should keep its hands off new keys.
> 
> That's clearly an unreasonable demand.  When new commands are added to
> Emacs, I see no reason to not bind them to some key.

I see no reason _to_ bind a command just because it's new.

And I was clear that there could be exceptions to the
(proposed) rule.

The point is that (1) there are few keys left, and (2) if
Emacs itself binds one of them, that's more limiting, in
effect, than if some 3rd-party library binds one of them.

To me, there's a problem: scarcity of available keys.
I proposed something that could help with that problem.
That's all.  Other suggestions for that?

> I also see no reason to not bind commands that were
> for one reason or another not bound when they were
> included in Emacs, 

As Eli is wont to say (correctly), we don't do things in
Emacs just because there's no known good reason not to.
We make changes when there are good reasons _to_ do so.

It's not just about `revert-buffer' not having been
bound when it was included in Emacs (Day One, probably).

It's that for all of Emacs's 35+ years it hasn't been
bound.  And I'm not aware of any requests (new or old)
for that.  (And none have been presented so far in this
discussion.)

The importance of that command, and its relatively
frequent and common use, together with the fact that it
has never had a default global key binding, and that no
one has even asked for such a binding, all argue against
a need for it to have such a binding.

> and are nowadays considered important enough to be
> bound to a key.

That's in question, isn't it?

And it's not about whether it's important for
`revert-buffer' to be bound to a key.  _I_ bind it to
a global key, myself, as one user.  It's about whether
it's important enough to be bound globally by default.

And I haven't seen here anything that's argued that
there's some particular "nowadays" need that wasn't
a need before.  No need expressed before, and no new
need expressed now.

And besides users binding `revert-buffer' (because
they find that useful), `revert-buffer' _is_ bound
by Emacs by default - in multiple modes, and often
to a mode-specific behavior (via variable
`revert-buffer-function').

The discussion of binding `revert-buffer' is only
about binding it globally by default.  That's what's
new, that's what's just been done.  And there's
been no "nowadays" need presented for that, AFAIK.