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

[Drew Adams <drew.adams@oracle.com>]

> > But no effort is needed for keys not yet bound
> > - zero, beyond documenting the fact.
>
> The effort, or the absence of effort, is not the
> important point here.

You're the one who brought up the "effort" needed
by Emacs to carry out this or that proposed change.
You claimed that your proposal needed less effort.
I argued that it needs more effort (> zero).

This was important enough that you brought it up.
Now it's not important.  OK.

> The main point is freedom: give more freedom to both Emacs and third-
> party libraries.  And "documenting the fact that keys not yet bound
> cannot be bound anymore" hinders Emacs' freedom.  I know, you also said that
> "exceptions would be possible with the approval of maintainers", but
> that's precisely what happened with the new "C-x x" key, and you
> objected anyway.

Maintainers decide.  I accept that - that's their
role, always, including on those occasions where
I might disagree.

The entire discussion was brought to emacs-devel
- not by me - from a bug thread, where `C-x x'
was taken over willy nilly, yes, over my objection.

And the bug/enhancement request was much narrower.
The decision was to bind a _global_ key by default.
Gigantic overkill, for the narrow problem raised
by the bug report.

I agreed (in emacs-devel, when discussed there,
and in the bug thread before that) that such wide
decisions - wider than the bug thread - should
preferably follow wider discussion in emacs-devel.

Half of the discussion in emacs-devel was/is about
this problem that some big, wide-ranging change
gets made in a bug thread, without many eyes seeing
it or minds discussing it.  That's a problem (IMO
- the maintainers disagree).

Wrt the actual change made:

I objected that, within the last year, first prefix
key `C-x p' was taken over, so I changed my code
to use `C-x x' instead, and now `C-x x' was also
taken over.  That's quite a bit to lose in a year.
And both changes were made in bug threads - no
discussion in emacs-devel.

I objected to that, and I still object.  It's not
I who decide, and that's fine.  But my opinion
that this isn't a good change, and that such things
should be discussed in emacs-devel, remains.

I'm not so worried as you about Emacs's "freedom"
to bind the keys it wants.  Casting this as a
question of "freedom" is alarmist and ridiculous,
IMO.  This is a question about what key-binding
conventions we should have, nothing more.

> > 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.
> 
> That just can't happen, it would be a arbitrary constraint that would
> impair Emacs' evolution, it would mean that hundreds of small or large
> potential improvements would not be possible anymore.

Not at all.  It would mean that Emacs would try
harder not to add new default key bindings.  It's
not trying hard enough now - that's the problem.
IMO, it's gotten worse lately, when we can least
afford it (available keys are scarcer and scarcer).

I asked for other solutions to the problem (still
asking).  And the maintainer's reply was that
there is no problem.

Yes, you proposed another answer to the problem,
and that's fine.  It's not as good an answer as
mine, IMO, but at least you offered something.

> > I would welcome any such support, if that
> > really is your intention.
> 
> FWIW, it was indeed really my intention.  The proposal is an attempt to
> find a reasonable middle ground that would give as much freedom as
> possible to Emacs, as much freedom as possible to third-party library
> developers, and without changing users' habits too much.

That's a good intention, though the ideas that
this is about "freedom", and that Emacs needs
more "freedom" to add default key bindings,
are misguided, IMO.

And as I said, by proposing to use a currently
bound key for this you increase, not decrease,
the contention and argument over which keys
Emacs should "lose" to this, and you increase,
not decrease, the need for users to change habits.