RE: Bikeshedding go! Why is <M-f4> unbound?

[Drew Adams]

> I don't think the argument that "if we bind <M-f4> to this function
> now, we won't be able to bind it to something else later" holds up
> for this key combination. 

AFAICT no one has argued that.  Certainly not I.

I mainly _asked_ what our reasons are for binding it.  (And the reasons given
have varied, BTW.)  AFAICT, we have not concluded _why_ we should do it, even if
some people are definitely in favor of doing it.

If we do this kind of thing it is good to know why, especially because we will
no doubt be having this same conversation again someday about some other outside
hotkey.


To the extent that I do argue against Emacs binding this key by default
(actually, I don't feel super strongly about it, it's just that the reasons in
favor have so far been so weak), my arguments are these:

1. Alt-f4 (or `M-f4') is an _easily repeatable chord_.  Unlike `C-x 5 0' or `C-x
C-c', you can repeat it by just holding it down.  Such keys are valuable - for
use in Emacs.  By users.  By Emacs libraries.  Finding such keys that are not
already bound or reserved or in some other way "taken" is getting harder.

I do not like for Emacs to gratuitously "waste" keys.  And this particular waste
seems pretty darn gratuitous to me, which is why I asked for the reasons behind
it.


2. Giving a default binding to this key will (yes, it seems to) discourage other
uses of it in Emacs.  Over time, default bindings sometimes become sacrosanct.

We have not even bound this key yet, but already the conversation is getting
overtones of gotta-have-it-and-respect-it-because-it-is-standard-out-there.
(See the end of this mail, for example.)

Slippery slope.  It won't be long before someone will complain that library
Foobar stomped on `M-f4', the universally recognized standard compulsory model
key for deleting a window and quitting an app.


3. Emacs has its own bindings and its own logic for key bindings.  We already
have keys to delete a frame and quit Emacs.

And, BTW, we do not waste repeatable keys/chords for that: `C-x 5 0' and `C-x
C-c' are not large sacrifices to these actions that are _not_ often repeated
consecutively (yes, if delete-frame had a repeatable key you could hold it down
to delete multiple frames in a flurry, but that is a negligible use case).

`M-f4', however, _would_ sacrifice a simple, repeatable key for an action that
is essentially not repeatable - a waste.


4. The argument that just _because_ a key is unbound we _should_ give it a
default binding is a non-starter, in my book.  Do I really need to explain why?

But that argument was actually advanced, and in just that arbitrary form:
_Because_ "it is otherwise unbound".  Since unspecific, that applies to all
unbound keys: we should bind them all by default?

Mallory might have climbed Everest "because it's there", but that should not be
why we make key bindings.  You cannot find a more gratuitous waste than such an
approach.


5. The argument that a key that is unbound might as well get a default binding
that fits the world outside Emacs begs the questions: which worlds (platforms)?
Which keys in that category - all of them?  And what about existing Emacs
bindings that already conflict with the outside world?


6. The strongest argument so far in favor of this binding, IMO, is the argument
that many, many users are already used to this key.

But it doesn't convince me, personally.  I would rather that we leave this key
unbound, so Emacs users and libraries do not hesitate (yes, some would) to put
it to good (better) use inside Emacs, in particular exploiting its property of
easy repetition in some way (e.g., for any repetitive or incremental action).


> The author of some new whiz-bang-mode might
> consider binding <M-f12> to whiz-bang-cool-new-function, but <M-f4> is
> already so well-known as the "close this window" key that I don't
> think you could seriously propose using it for anything else at this
> point.

See #1 and #2 above.  It's happening already: "So well-known" trumps being able
to put it to better use _within and for_ Emacs.

Poor Emacs.