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

[Drew Adams]

> No one has argued that it should not be possible to bind
> M-f4, just as today.

Yes, Lennart, we agree about that.

> It looks to me you are mixing the question whether M-f4 should be
> possible to bind with what should happen when it is unbound.

No, I am not mixing them.  I am saying that for the same reason we want users to
continue to be able to bind M-f4, I want them to continue to be able to
determine what happens when it is unbound.  Let users decide how Emacs behaves.
We don't need to decide this for them.

> > I think (but am not sure at this point) that your position 
> > is (a): you want to hard-code the behavior that unbound
> > Alt+F4/M-f4 should always be sent to w32.
> 
> I have nothing against making it a user choice.

If you have nothing against it, then you agree to making it a user choice.  A
user should be able to configure Emacs to reflect her preferred default behavior
at startup and also change the behavior at runtime.  User choice.

> (It can't be a library choice AFAICS since no library is
> involved for an unbound key, but of course
> a library coiuld provide ways for the user to make this choice.)

Any Lisp code today can decide to capture the unbound error using
`condition-case', as mentioned earlier.  You can determine at the Lisp level
what happens when an unbound error is raised.

If the behavior of unbound M-f4 is determined by a variable, and if the value is
set to `error-if-unbound', then Lisp code can still do tomorrow what it can do
today.  But only if the value is `error-if-unbound'.

> I have asked you what advantage you see giving a
> "not bound" error message when a key is unbound.

See my response to the same question from Oscar.  Today, users and Lisp code can
take any action they want in this regard.  Why prevent that tomorrow?  Why take
away user control?

Your initial position was, I think, that Emacs must _always_ pass Alt-f4 to w32
(I could be wrong).  Now you agree to letting Emacs users bind it and keep
control if they want.  Good.  Why not give them complete control over the
behavior?  What do you lose by giving them more choice?

By making this a user option, the only remaining question becomes the default
value.  You would no doubt argue for pass-through-if-unbound.  I would argue for
error-if-unbound.  But we should at least be able to agree on letting the user
decide, whatever the default behavior might be.