RE: [External] : Re: PROPOSAL: Repurpose one key (why only one?) and reserve it for third-party packages

[Drew Adams]

(I haven't read all of your long message here.
And I wouldn't have bothered to reply to it,
if I hadn't noticed that you mention me in
passing, and you did so inaccurately.)
___

> There are no package authors except of Drew, who
> asked for "some key" to be re-purposed for their
> specific package.

No, I never, ever, asked for any Emacs keys to
be repurposed for any of my libraries.

I asked that keys that were _not_ yet bound by
Emacs by default, continue to NOT be bound by
Emacs by default.  That's all.  No repurposing
- for my benefit or for any other reason.

Before that general request, I asked that the
unbound (by default) prefix key `C-x p' NOT
suddenly be bound by Emacs by default.  To no
avail - my polite plea was ignored.

I later asked that the unbound (by default)
key `C-x x' NOT be bound by Emacs by default.
To no avail - my plea was ignored.

It was only recently that I asked more generally
that (barring discussion followed by exceptional
maintainer decision) _NO_ new keys be bound by
Emacs by default - we should have a moratorium
on doing that.  To no avail, so far.

> There was no real problem in the first place as
> there was no contradictory forces against each other.

Not sure what you're referring to, but there is
a very real problem of Emacs binding more and
more keys by default - the set of keys still
unbound by default is dwindling to extinction.

This is not a problem for _users_.  At least not
directly.  Users can always bind any keys they
like.  It's a problem for 3rd-party code (and
thus indirectly for its users).  There need be
no discussion about what users can do - they
are welcome to do anything, and the conventions
explicitly say so.

> packages anyway can re-purpose keys without asking
> Emacs development team.

Sure, 3rd-party code _can_ do anything, without
regard to anyone else.  We're talking about GNU
Emacs key-binding _conventions_: rules for
playing well together.

It's much more constraining on 3rd-party code
when Emacs itself binds a key by default, than
when some other 3rd-party code binds the same
key by default.  This has all been explained,
with good arguments.  No one has argued to the
contrary.  When Emacs itself does something
like that, it changes the game for everyone.

It's not helpful for people here to simply
ignore the discussion that's taken place (in
emacs-devel and bug threads), and instead add
repetition of Q&A and arguments.  Please read
the discussion, so arguments aren't repeated
here needlessly, wasting everyone's time and
energy.

(That is, do that if you're really interested
in the question/problem.  If you're not, then
don't bother.  But please don't just repeat
questions or arguments here that have already
been made in the more general discussion.)

Again, it's not I who spread this discussion
from bug threads to emacs-devel, or to this
user help list.

Raising the discussion on emacs-devel was a
_good_ thing.  But there's little sense in
ignoring what's already been said, and
starting over again here.  Everyone's welcome
to add their voice in any way to the existing
discussion.  But please _add_, cognizant of
what's already been said.

> But people wish to solve the problem for
> imaginary package authors who did not even
> complain. The one who complained is Drew Adams

Actually, several people have argued that the
problem exists.  You seem to be ignoring the
general discussion and just imagining things.

I was the one who brought up the problem, yes.
But I brought it up in the context of bug
discussions where new default key-binding
actions were being discussed.  Yes, I objected
to those proposed actions.

Had the initial grabbing of a prefix key for
Project chosen a key that I wasn't already
using for (many) Bookmark+ commands, it's
unlikely I would have said anything.

I spoke up then because that change affected
me and users of my library directly.  I asked
politely that they choose some other prefix
key to grab for Project.  My request was
rejected summarily, just because my code is
3rd-party.

Or perhaps because the request was from me
(?) - the reason given was just that Emacs
dev is under no "obligation" to respect
such a request, which is of course true
and uncontested - no obligation.  But some
consideration would have been nice.

It was not even I who took the discussion
from bug threads to emacs-devel.  So no,
I'm not the only person who recognizes the
problem.

> Right now, how it is, and due to convention,
> many packages will simply NOT set global key
> bindings but ask the user to set it.

This is a false dichotomy.  Use of any 3rd
party code is optional.  No one's forced to
load any library.  Everyone agrees that in
general, when it makes sense, it's more
polite for just loading a library not to
change Emacs session state (beyond loading
definitions etc.).

But there are all kinds of 3rd-party code.
There's little real difference between adding
a keymap & providing a command to activate it,
and just activating it by default, provided
doc or commentary makes clear what happens.

I have code that does one and code that does
the other.  And I have code that just suggests
key bindings, in comments.  In general, more
important and larger libraries, with more
users, need to be handled more carefully. 

It's important to understand the reasons
behind any convention - the context and
scope for its action.

Consider, for example, the convention that
functions (including commands) shouldn't
change or bind user option values.

Emacs itself provides functions and commands
that do just that.  Otherwise there would be
no way to do it!

Does that (good, reasonable) convention mean
that 3rd-party code should never provide
commands, menus, UI's, etc. that users can
use to change option values, face values,
etc.?  Of course not.

And yes, I have code that provides such
UI's, e.g., code that lets you tweak face
values incrementally, showing the effect
as you do so.  And I have code that helps
improve the Customize UI.

There's no rule against improving Emacs by
offering such things - that would be absurd.
(And the conventions apply to Emacs's own
code also, not just to 3rd-party code.)

That convention is only a general guideline,
which points out that it makes no sense, and
it can be impolite, usually, for 3rd-party
code to change preferences that a user has
set.  But such a rule clearly doesn't apply
to code whose very purpose is to help a
use choose and set such preferences.

This _should_ be obvious.  But even Emacs
developers (misguidedly, IMO) shy away from
_binding_ user options within a function,
even if the purpose of the function involves
temporarily using a different value.  To me
that's misunderstanding, taking the guideline
as a hard-&-fast rule, and not understanding
the logic behind it.