RE: Bikeshedding "user choice"

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

>  > Calm down, please; no need to shout.
> 
> That was not "shouting", that was the 2x4 which seems to be essential
> for getting the mule's attention.

And no need for name-calling.

> nobody proposes to change Emacs's behavior with respect to
> unbound keys.  Lennart ... proposes to allow implicit binding
> via the GUI environment, as well as explicit binding within
> Emacs. Ie, his proposal is really to change the definition of
> "bound".

A radical change to the definition of "bound" for Emacs is a proposal to change
Emacs's behavior wrt unbound keys.

> Lennart wants "delegate to OS" to be the fallback for *all* keys,
> *not* restricted to M-F4....   currently the default is "if Emacs
> doesn't explicitly bind a key, by default stroking it leads to
> an error", and Lennart proposes to change that default to "if
> Emacs doesn't explicitly bind a key, look a little harder to see
> if the environment binds it."
>
> What Lennart wants, as far as I can tell, is
> (1) Emacs can explicitly (un)bind a key (the "unbound" state is
>     achieved with `(define-key map key nil)').  In case of an
>     explicitly unbound keystroke, Emacs will signal an unbound error.
> (2) If (1) does not hold, then Emacs will *implicitly* bind the key to
>     an action determined by the GUI if the GUI defines one.
> (3) If neither (1) nor (2) holds, Emacs signals an unbound error when
>     the key is stroked.
> 
> This is a change in the definition of "binding".

I understood Lennart the same way (except that as he pointed out it is an
unbound message, not an unbound error).

I disagree that this is the right approach.  I prefer that the set of keys for
which pass-through is currently effective be explicit within Emacs, for users
and Lisp.

If each key for which we want pass-through has an Emacs binding that specifies
this (pass-through), then it is clear to everyone what that key does in Emacs
(it is handled by the OS).  Likewise, for Stefan's alternative of using
`w32-passthrough-events'.

Otherwise (in Lennart's proposal as you have described it):

1. To turn off this behavior globally, you must bind each Windows hotkey to nil
explicitly (unless it is already bound to an Emacs command).

How do you find all such hotkeys?  Examine the Windows doc...  But wait?!
Applications and hardware OEMs can assign Windows hot keys too.  How do you find
them all?  Search the registry?

2. Since "bound" would have a new meaning in Emacs, what would key lookup
mean/do?  Until now, being unbound has been effectively the same as having a nil
binding.  And your (1) above maintains that terminology - OK.

So now how does your code distinguish "unbound" as a nil binding from "neither
bound or unbound" (no explicit binding, either command or nil)?  If M-f4 is not
bound to nil or to a command then is it unbound?  bound?  Well, your (2) says
that Emacs will have *implicitly* bound it to a GUI action (if available).

Sometimes people mean "automatically" when they say "implicitly", so let's
check: Does "implicit" here mean just automatic, so that once this binding has
been created automatically it is seen in Emacs Lisp as a (normal) binding?  Or
is there never any Emacs binding, just a virtual, extra-Emacs binding?

In the latter case (which I'm guessing you mean), how can Lisp code determine
whether a given key has an effect (let alone what that effect might be)?

Will `lookup-key' change, or will it still return nil for a key that has not
been given any explicit binding (nil or otherwise)?  In the latter case it does
not distinguish a key that will be handled by Windows from a key which has been
explicitly bound to nil.

It is far better IMO to make such connections between keys and actions explicit,
for Emacs users and at the Lisp level.  Use an explicit Emacs binding:
(define-key KEY 'w32-syskey).  Or use an explicit mapping variable such as
`w32-passthrough-events'.  Users and Lisp code can then see what's happening,
and it is trivial to turn it off, all of it.

And if tomorrow some new app or new hardware changes Windows to add its own
global hotkey, then nothing changes in Emacs (POLA), since the key was not added
at the Emacs level (binding to `w32-syskey', or `w32-passthrough-events entry).
What Emacs users and code see, in Emacs, is what they get.