Bikeshedding "user choice"

Bikeshedding "user choice"

[Stephen J. Turnbull]

Drew Adams writes:

 > Do I really need to state why I prefer giving users more choice?

No, you don't.  Since whether or not to give users choice is a matter
of design, it is a matter of taste.  De gustibus non est disputandum.

However, if you want to convince other people, you do.  It is far from
obvious that maximizing user choice is a good thing.  In fact, the
whole point of "automation" is to *free* the user of the need to make
choices.

Applied to the original thread, once the user has the capability of
binding a key, then she has the choice to bind it to `ignore' or
`unbound-event-error'.  So, the question is about defaults.  In
general, if Emacs (core, library, or user) hasn't bound the key, fall
back to OS if available seems like a good idea (POLA).  The additional
option to change the default fallback (yikes!) that you advocate is a
YAGNI (yes, even *you* don't *need* it!)

RE: Bikeshedding "user choice"

[Drew Adams]

> In general, if Emacs...hasn't bound the key, fall back
> to OS if available seems like a good idea (POLA).

Show a `... is unbound' message is also a good idea.
That's the standard behavior in Emacs (POLA).

> once the user has the capability of binding a key, then she
> has the choice to bind it to `ignore' or `unbound-event-error'

Or to a command that passes it through to the OS?  That would be the way we
normally define keys in Emacs.  Including the way we define default bindings.

I would prefer that approach to a `w32-passthrough-events' option, as I
mentioned.  For one thing, `C-h M-f4' etc. would tell you what the key does (at
least that it is passed to the OS).  But mainly it just fits how we handle keys
in Emacs.

But I'm assuming that that approach is not feasible or it would have already
been discussed in terms of implementation.

> The additional option to change the default fallback
> (yikes!) that you advocate is a YAGNI (yes, even *you*
> don't *need* it!)

Are you referring to the `w32-passthrough-events' option, which Stefan came up
with?  Yes, I think it's a good idea that if an unbound key isn't listed in the
option then Emacs shows its usual that-key-is-unbound message.

That message is the standard Emacs behavior for an unbound key.  And no, an
unbound key is not the same as a key bound to `ignore' or to a command that
echoes `... is unbound'.

> the question is about defaults.

I haven't argued strongly about the default behavior.  I expressed my preference
(leave `M-f4' unbound), but I said clearly that it's not terribly important.
Bind it to M-f4 by default and Emacs users will be astonished.  Leave it unbound
and Windows users new to Emacs will be astonished.

> Sure, but surprising Emacs users doesn't matter much because
> *the key is normally unbound*, and therefore they won't be
> stroking it....

Ever hit a key accidentally?  Ever use `C-h k' to see what a key does?  Ever
change platforms?  I can see at least some Emacs users being surprised on
Windows when they hit the key and Emacs quits.

> Surprising Windows users does matter because *the key is
> normally bound*, and those who use that shortcut will be
> mightily annoyed.

Sure, no one suggested the contrary.  Windows users (and others) are surprised
and mightily annoyed at first by many things in Emacs.

And no, I don't say that as a reason to increase their annoyance by adding one
more nuisance.  I've recognized this annoyance from the beginning.  There are of
course lots of Windows users who never use Alt-f4, but that doesn't lessen the
hurt for those who do.

> Unless your goal is to cause as much pain for newbies as
> possible as long as it doesn't also cause pain for old farts
> (of whatever age)?  That seems perverse to me, though.

No, that's not my goal.  I don't have a goal wrt the default behavior.  I've
been clear about that.  I am fine with either default behavior for the key.  I
have my own preference, but I don't feel strongly about it.

RE: Bikeshedding "user choice"

[Stephen J. Turnbull]

Drew Adams writes:

 > > In general, if Emacs...hasn't bound the key, fall back
 > > to OS if available seems like a good idea (POLA).
 > 
 > Show a `... is unbound' message is also a good idea.
 > That's the standard behavior in Emacs (POLA).

Of course it is NOT the standard behavior in Emacs!  ALL normal keys
are normally bound, ALL control characters are normally bound, MOST
meta characters are normally bound.  The STANDARD BEHAVIOR of Emacs is
"All Keys Yours Now Emacs Keys Are" and they do something!  Arguing
from "standard behavior" of Emacs suggests that we bind this key now!

IOW, Lennart's proposal doesn't change the usual *behavior* of Emacs
(pressing a key usually does something).  It only changes the way it
is implemented (by delegating "choice of something" to the OS).  Of
course, in the case of this particular key, Emacs doesn't bind it, and
in that minor sense it changes behavior.  But get real; Emacs is not
about avoiding binding key sequences.  Emacs is about binding
everything in sight.  Heck, even the standard argument for not binding
a key sequence is "it might turn out to be useful and then people
would object to us binding it to something else in the future"!

 > > once the user has the capability of binding a key, then she
 > > has the choice to bind it to `ignore' or `unbound-event-error'
 > 
 > Or to a command that passes it through to the OS?  That would be the way we
 > normally define keys in Emacs.  Including the way we define default
 > bindings.

"Frankly, my dear, I don't give a damn" how GNU Emacs implements this
default; I only care what the default is.  I imagine that Lennart
feels the same way.

 > I would prefer that approach to a `w32-passthrough-events' option, as I
 > mentioned.  For one thing, `C-h M-f4' etc. would tell you what the key does (at
 > least that it is passed to the OS).

I would not consider this feature complete if C-h M-F4 didn't do that
no matter how pass-through is implemented.

 > Ever hit a key accidentally?  Ever use `C-h k' to see what a key does?  Ever
 > change platforms?  I can see at least some Emacs users being surprised on
 > Windows when they hit the key and Emacs quits.

Sure, and so what about it?  Unless they have some other binding in
mind (in which case they should bind the key in .emacs and maybe lobby
on emacs-devel for making it the default binding), they won't do
*that* again.  People who *are* used to using it will find it to be a
serious annoyance.  The same argument about binding it and lobbying on
emacs-devel applies, of course.  Oops.  That's exactly how this thread
started!

 > No, that's not my goal.  I don't have a goal wrt the default behavior.  I've
 > been clear about that.

Not really, because you keep arguing implementation with people who
only care about the default behavior, and don't care about
implementation.  But you keep claiming that various implementation
strategies would result in bad behavior (though not necessarily of the
key itself, eg, what would C-h k do).  That isn't necessarily true (it
depends on how thorough Stefan and Yidong are about insisting that all
behavior be consistent with current behavior, *except* for the default
action of "keys not explicitly bound in Emacs"), you know.  Me, I get
the strong impression that despite disclaimers you *do* care about
default behavior (again, not necessarily of the key itself).

RE: Bikeshedding "user choice"

[Drew Adams]

>  > > In general, if Emacs...hasn't bound the key, fall back
>  > > to OS if available seems like a good idea (POLA).
>  > 
>  > Show a `... is unbound' message is also a good idea.
>  > That's the standard behavior in Emacs (POLA).
> 
> Of course it is NOT the standard behavior in Emacs!  ALL normal keys
> are normally bound, ALL control characters are normally bound, MOST
> meta characters are normally bound.  The STANDARD BEHAVIOR of Emacs is
> "All Keys Yours Now Emacs Keys Are" and they do something!  Arguing
> from "standard behavior" of Emacs suggests that we bind this key now!

Calm down, please; no need to shout.  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 get real; Emacs is not about avoiding binding key sequences.
> Emacs is about binding everything in sight.

Not necessarily by default.  We do not bind keys by default simply because they
are not yet bound.

> Heck, even the standard argument for not binding
> a key sequence is "it might turn out to be useful and then people
> would object to us binding it to something else in the future"!

Yes.  M-f4, for instance. ;-)

> I only care what the default is.

Then why all the energetic venom here?  You are not arguing here about the
default behavior of M-f4 or responding to a post about that.  Why not reserve
your comments for discussion of the default, if that's all you care about?

>  > I would prefer that approach to a `w32-passthrough-events' 
>  > option, as I mentioned.  For one thing, `C-h M-f4' etc. would
>  > tell you what the key does (at least that it is passed to the OS).
> 
> I would not consider this feature complete if C-h M-F4 didn't do that
> no matter how pass-through is implemented.

(I (and I guess you too) meant `C-h k M-f4' (forgot the `k').)

So I guess we agree about this, at least.  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 don't have a goal wrt the default behavior.  I've been clear
>  > about that.  I am fine with either default behavior for the key.
>  > I have my own preference, but I don't feel strongly about it.
> 
> Not really, because you keep arguing implementation

No, I have not mentioned implementation.  I know nothing about how pass-through
and the rest of the machinery would or should be implemented.  I've discussed
only the user level.

> with people who only care about the default behavior, and don't care about
> implementation.  But you keep claiming that various implementation
> strategies would result in bad behavior (though not necessarily of the
> key itself, eg, what would C-h k do).

Again, I have not discussed implementation strategies, though perhaps I don't
know what you mean by that.  Certainly I've been absent from the subthreads
concerning C-code implementation.

About the only things I've said that might touch on "implementation" were:

1. I'm OK with Stefan's proposal of option `w32-passthrough-events'.

2. If it is feasible to just bind M-f4 to an Emacs command that signifies
pass-through (i.e., that passes the key sequence to Windows), then I would
prefer that to `w32-passthrough-events'.

My point of view here is only at the user level; I have nothing to say about how
either approach (or any other) might be implemented.

And I have discussed the default behavior of M-f4 very little.  I've said what
my preference is (leave it unbound) and stated clearly that I don't feel
strongly about the default behavior.

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.

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.

RE: Bikeshedding "user choice"

[Drew Adams]

>  > 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.

RE: Bikeshedding "user choice"

[grischka]

> 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'.

What if I want Alt-f/e/o/... to activate menus "File/Edit/Options/..."
and also for all other menus that some package might possibly add?

Are you proposing that I need to define one "pass-through" for each
of "Alt-a..z", just in case?

Also what if some package thinks it wants to bind M-f in some local
map which I would't really care except that I do care that my menu
shortcut now stops working?

--- grischka

RE: Bikeshedding "user choice"

[Drew Adams]

> > 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'.
> 
> What if I want Alt-f/e/o/... to activate menus "File/Edit/Options/..."
> and also for all other menus that some package might possibly add?
> Are you proposing that I need to define one "pass-through" for each
> of "Alt-a..z", just in case?

Presumably Emacs would provide a command `w32-menu-accel' (or you could write it
yourself), which would do just that.  It would either set all of those
pass-throughs or set them all to nil: on/off.  (Modulo any existing bindings.) 

And if, as seems ever more likely, it's decided to give users more or less all
of Windows by default, then enabling would be the default: each of those
pass-throughs would be predefined.

`All Of Windows', now playing in an Emacs near you.
http://support.microsoft.com/kb/126449

> Also what if some package thinks it wants to bind M-f in some local
> map which I would't really care except that I do care that my menu
> shortcut now stops working?

Are you saying that you now want to _preclude_ Emacs from creating bindings that
interfere with Windows menu accelerators?  Or that interfere with `Alt-f4' or
`Alt-f6' or `Alt-down' or... any other Windows keys...?

We have not see the last of this...

Re: Bikeshedding "user choice"

[grischka]

Drew Adams wrote:
>> Also what if some package thinks it wants to bind M-f in some local
>> map which I would't really care except that I do care that my menu
>> shortcut now stops working?
> 
> Are you saying that you now want to _preclude_ Emacs from creating bindings that
> interfere with Windows menu accelerators?  Or that interfere with `Alt-f4' or
> `Alt-f6' or `Alt-down' or... any other Windows keys...?

I was merely asking a question.  Just the fact that a feature is
maybe in Windows should not stop you to think logically.

However as to menu accelerators it would indeed make sense to look
for a solution that works also for e.g. GTK or even the built-in
text-mode menu.

--- grischka

> We have not see the last of this...