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

[Drew Adams]

> I can't see that there is something like an "unbound error" when
> entering a key that it not bound. All I can see is a message saying
> "THE-KEY is undefined".

Yes, Lennart, that is what I meant - that error.  Sorry if that wasn't clear.

> How do you get that "unbound error"? 

By hitting a key in Emacs that is not bound in Emacs and that doesn't get
grabbed by something outside Emacs.

> I got the impression from this
> discussion that your code somehow depends on it.

My code has absolutely nothing to do with it.  Zero.  Nada.  I have no code that
has anything to do with this, and I do not foresee having any.

Dunno how you imagined that, but I seriously doubt that you "got the impression
from this discussion".  Or else you're not reading well.

I simply do not see why we should remove control from users for no particular
reason.  That's all.

Why are you arguing against continuing to grant them this control they have now?
You've agreed that they can continue to bind M-f4.  Why not let them also write
code that does something when the Alt-f4 key is pressed and Alt-f4/M-f4 is not
bound?  Why are you trying to prevent that?  What do you care?

What's the cost?  What's the big deal?
I repeat all that I've suggested:

d>  (a) let users bind `M-f4' in Emacs, but if unbound
d>  (b) look it up in `w32-passthrough-events' and
d>      if there pass it to Windows, or if not there
d>  (c) raise an unbound error.

Is that a big deal?  The only thing I added to Stefan's suggestion was (c).  He
did not say what he envisioned for case (c).  What do you propose for (c)?

We can discuss what the default value of `w32-passthrough-events' should be.  In
particular, whether it should contain the key Alt-f4/M-f4. (You would argue yes,
me no - but I don't feel strongly about that, as I've said several times now.)

But let's at least agree to give users and their code the choice this way,
letting them handle/access the unbound error for _any keys_ if they want to.
They may never want to.  But why proscribe it?

And in terms of cost I get the impression that this approach is a relatively
simple one.  At least that's how Stefan characterized it:

s> A simpler solution is to dump the problem onto the user:
s> setup a `w32-passthrough-events' where the user can specify
s> events that should be passed on to Windows's standard lib
s> rather than handled by Emacs.

Do I have a special use case in mind for handling such unbound errors?  No, I do
not.  The ways people use Lisp are unlimited.  And handling raised errors is one
control mechanism they sometimes use.

If you were to propose that we remove the possibility that anyone can use `setq'
to set a variable to the value `5792468', I would not have a use case in mind to
counter that either.  But I'd have the same reaction and make the same argument:
WTF? Why limit users this way, if you don't have to?