RE: Bikeshedding "user choice"

[Stephen J. Turnbull]

Drew Adams writes:

 > 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.  Now that I've got it, no further
need. ;-)

 > It should have been clear from the previous sentence (and the
 > entire context) that I was saying that this is the standard
 > behavior in Emacs _for an unbound key_.  Which it is.

But it's irrelevant, because nobody proposes to change Emacs's
behavior with respect to unbound keys.  Lennart's proposal, at least
as I understand it, is more radical.  He 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".

 > Then why all the energetic venom here?  You are not arguing here
 > about the default behavior of M-f4

In one sense, I am.  "Delegate to OS" is indeed a behavior, even if it
is non-deterministic within Emacs.  In another sense, I'm not, though
I don't think it's in the sense you mean.  In particular, I think that
Lennart wants "delegate to OS" to be the fallback for *all* keys,
*not* restricted to M-F4, and I tend to agree (as long is it's
possible to determine when there is no such fallback behavior).

 > or responding to a post about that.  Why not reserve your comments
 > for discussion of the default, if that's all you care about?

For everybody else, *this thread* is still really discussion of the
default, in the sense that 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."

 > But I think that some have indicated they would prefer that M-f4
 > (or Alt-f4) be sent to Windows regardless of whether it is preceded
 > by a prefix key, IOW whenever that key is hit.

I'm sure that is the behavior of "intercepting" window managers in X11
GUIs.  I don't really recall whether anybody indicated they *prefer*
that, and that is part of the spec that needs clarification.

 > Clear enough now?  I have no strong feelings about the default.
 > Make M-f4 do _anything you want_ by default.  My posts have
 > generally been about what happens when M-f4 is not bound and how
 > users see and interact with this binding or lack of binding.

You haven't expressed a full understanding of the proposal that I can
see, specifically ISTM that you are obsessed with focusing on M-F4.
It's more general than just M-F4, although that is the particular key
that triggered the thread.  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".

Depending on the details of the GUI implementation, it might be
preferable to do this via an explicit action in Emacs (eg, if there is
no way to determine if the GUI provides an action), or it might be
preferable to do it at the C level (eg, so it could apply to keys that
Emacs doesn't know about at all).  But we need to figure out whether
this is desirable; it's not just about M-F4, it's about *all* keys
that Emacs hasn't yet chosen to bind.