RE: Bikeshedding "user choice"

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

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

[Deniz Dogan]

Is there any particular reason to why <M-f4> is not bound to something
like `save-buffers-kill-terminal' in Emacs?

I think <M-f4> (or Alt+F4) can be seen as a pretty standard key
binding for quitting a graphical application these days.

-- 
Deniz Dogan

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

[Óscar Fuentes]

Deniz Dogan <deniz.a.m.dogan@gmail.com> writes:

> Is there any particular reason to why <M-f4> is not bound to something
> like `save-buffers-kill-terminal' in Emacs?

In KDE, pressing Alt-F4 is the same as clicking on the close button. The
keypress is intercepted by KDE and Emacs never sees it. IIRC that's not
the case for Windows.

> I think <M-f4> (or Alt+F4) can be seen as a pretty standard key
> binding for quitting a graphical application these days.

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

[Deniz Dogan]

2011/1/5 Óscar Fuentes <ofv@wanadoo.es>:
> Deniz Dogan <deniz.a.m.dogan@gmail.com> writes:
>
>> Is there any particular reason to why <M-f4> is not bound to something
>> like `save-buffers-kill-terminal' in Emacs?
>
> In KDE, pressing Alt-F4 is the same as clicking on the close button. The
> keypress is intercepted by KDE and Emacs never sees it. IIRC that's not
> the case for Windows.
>

I don't know about KDE, but on Windows it says the key is undefined.

So is there any problem in binding it on Windows?

-- 
Deniz Dogan

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

[Eli Zaretskii]

> From: Deniz Dogan <deniz.a.m.dogan@gmail.com>
> Date: Wed, 5 Jan 2011 18:11:12 +0100
> Cc: emacs-devel@gnu.org
> 
> > In KDE, pressing Alt-F4 is the same as clicking on the close button. The
> > keypress is intercepted by KDE and Emacs never sees it. IIRC that's not
> > the case for Windows.
> >
> 
> I don't know about KDE, but on Windows it says the key is undefined.
> 
> So is there any problem in binding it on Windows?

I don't think so.  AFAIK, Alt-F4 is a window manager keybinding, not
an Emacs keybinding.  The MS-Windows "window manager" doesn't have
that binding.

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

[Deniz Dogan]

2011/1/5 Eli Zaretskii <eliz@gnu.org>:
>> From: Deniz Dogan <deniz.a.m.dogan@gmail.com>
>> Date: Wed, 5 Jan 2011 18:11:12 +0100
>> Cc: emacs-devel@gnu.org
>>
>> > In KDE, pressing Alt-F4 is the same as clicking on the close button. The
>> > keypress is intercepted by KDE and Emacs never sees it. IIRC that's not
>> > the case for Windows.
>> >
>>
>> I don't know about KDE, but on Windows it says the key is undefined.
>>
>> So is there any problem in binding it on Windows?
>
> I don't think so.  AFAIK, Alt-F4 is a window manager keybinding, not
> an Emacs keybinding.  The MS-Windows "window manager" doesn't have
> that binding.
>

That sounds strange, but I suppose that's reasonable to assume. Do
"all of the other" Windows applications make this binding themselves?

-- 
Deniz Dogan

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

[Óscar Fuentes]

Deniz Dogan <deniz.a.m.dogan@gmail.com> writes:

>>> > In KDE, pressing Alt-F4 is the same as clicking on the close button. The
>>> > keypress is intercepted by KDE and Emacs never sees it. IIRC that's not
>>> > the case for Windows.
>>> >
>>>
>>> I don't know about KDE, but on Windows it says the key is undefined.
>>>
>>> So is there any problem in binding it on Windows?
>>
>> I don't think so.  AFAIK, Alt-F4 is a window manager keybinding, not
>> an Emacs keybinding.  The MS-Windows "window manager" doesn't have
>> that binding.
>>
>
> That sounds strange, but I suppose that's reasonable to assume. Do
> "all of the other" Windows applications make this binding themselves?

IIRC, on Windows all events (*) go to the application first. The
application usually delegates into a Windows API fallback the handling
of the events it doesn't know about. So you can handle Alt-F4 on your
app and do whatever you want, as Emacs does, or delegate into the
Windows API function (ProcessMessages ?) which performs the standard
action associated with the event (if any) as 99% of Windows apps do.

IMO, Emacs is doing the right thing, because it allows treating Alt-F4
as just another key combination. I see no problem binding Alt-F4 to some
exit function, as long as the user can override that.

* There is a mechanism for intercepting events before they are seen by
  ordinary applications (global hooks). There are some events too that
  are always handled by the OS due to security reasons.

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

[Lennart Borgman]

On Wed, Jan 5, 2011 at 7:15 PM, Óscar Fuentes <ofv@wanadoo.es> wrote:
>
> IIRC, on Windows all events (*) go to the application first.

Nearly all, but some events are never sent to the application. (At
least not if you are running Windows the normal way.)

An example of a combination that is not sent to the application is
Alt+Tab. (This creates some problems when you are using Alt as Emacs
META. M-TAB is commonly used in Emacs for completion. That does not
work on w32 if you have META on the Alt key - which is default and
actually the only reliable choice in the current (unpatched) Emacs.)

> The
> application usually delegates into a Windows API fallback the handling
> of the events it doesn't know about. So you can handle Alt-F4 on your
> app and do whatever you want, as Emacs does, or delegate into the
> Windows API function (ProcessMessages ?) which performs the standard
> action associated with the event (if any) as 99% of Windows apps do.
>
> IMO, Emacs is doing the right thing, because it allows treating Alt-F4
> as just another key combination. I see no problem binding Alt-F4 to some
> exit function, as long as the user can override that.

I think the binding of Alt-F4 is not that important in a non-multi
document interface (but that is just my opinion).

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

[Drew Adams]

> M-TAB ... does not work on w32 if you have META on the
> Alt key - which is default and actually the only reliable
> choice in the current (unpatched) Emacs.

Lennart, you keep saying that here and there.
But you've never backed up that claim, AFAICT.

Here's a typical example (see also the two followups for your complete claim):
http://lists.gnu.org/archive/html/help-gnu-emacs/2010-03/msg00063.html

You keep telling users that they cannot use `M-TAB' on Windows, but it is simple
for a user to have `M-TAB' (as well as `ESC TAB') be handled by Emacs on
Windows.


> I think the binding of Alt-F4 is not that important in a non-multi
> document interface (but that is just my opinion).

There is no reason for Emacs to bind Alt-F4 (or M-f4) by default.
It should be kept for anyone to bind to anything.  (Just one more opinion.)

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

[Stuart Hacking]

On 10 January 2011 01:01, Drew Adams <drew.adams@oracle.com> wrote:
>
>> I think the binding of Alt-F4 is not that important in a non-multi
>> document interface (but that is just my opinion).
>
> There is no reason for Emacs to bind Alt-F4 (or M-f4) by default.
> It should be kept for anyone to bind to anything.  (Just one more opinion.)
>

On the other hand, it wouldn't be a big deal for Emacs to have a
default binding. Anyone who cares enough will be able to rebind it.

There's always discussion about making Emacs a more well behaved
application on Windows and this seems like a low-hanging fruit?

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

[Drew Adams]

> > There is no reason for Emacs to bind Alt-F4 (or M-f4) by default.
> > It should be kept for anyone to bind to anything.  (Just 
> > one more opinion.)
> 
> On the other hand, it wouldn't be a big deal for Emacs to have a
> default binding. Anyone who cares enough will be able to rebind it.
> 
> There's always discussion about making Emacs a more well behaved
> application on Windows and this seems like a low-hanging fruit?

I respectfully disagree.

1. There's _no special reason_ to give _this_ key a default binding.

2. While it is true that a default binding can be overridden, that's not a good
enough argument for making a _particular_ default binding.

3. Default bindings tend to become sacrosanct in the eyes of many over time.  A
library (or even a user) that binds one can be thought by some to be going
against the grain (convention).

4. It's not because some key is unbound that we should give it a default
binding.  If the argument that a default binding can always be overridden were
sufficient for creating default bindings, then we would bind _every_ key by
default.  Even a random default binding would be bound to please someone, and
"Anyone who cares enough will be able to rebind it."

5. Slippery slope.  Windows uses key XYZ for blah, so we bind it.  Then someone
says "Hey, we respect the Windows binding by default for XYZ, why not also for
UVW and RST and ...?

"It wouldn't be a big deal for Emacs to have a default binding" - epitaph on a
tombstone in Boot Hill, Tombstone, Arizona.

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

[Deniz Dogan]

2011/1/12 Drew Adams <drew.adams@oracle.com>:
>> > There is no reason for Emacs to bind Alt-F4 (or M-f4) by default.
>> > It should be kept for anyone to bind to anything.  (Just
>> > one more opinion.)
>>
>> On the other hand, it wouldn't be a big deal for Emacs to have a
>> default binding. Anyone who cares enough will be able to rebind it.
>>
>> There's always discussion about making Emacs a more well behaved
>> application on Windows and this seems like a low-hanging fruit?
>
> I respectfully disagree.
>
> 1. There's _no special reason_ to give _this_ key a default binding.
>
> 2. While it is true that a default binding can be overridden, that's not a good
> enough argument for making a _particular_ default binding.
>
> 3. Default bindings tend to become sacrosanct in the eyes of many over time.  A
> library (or even a user) that binds one can be thought by some to be going
> against the grain (convention).
>
> 4. It's not because some key is unbound that we should give it a default
> binding.  If the argument that a default binding can always be overridden were
> sufficient for creating default bindings, then we would bind _every_ key by
> default.  Even a random default binding would be bound to please someone, and
> "Anyone who cares enough will be able to rebind it."
>
> 5. Slippery slope.  Windows uses key XYZ for blah, so we bind it.  Then someone
> says "Hey, we respect the Windows binding by default for XYZ, why not also for
> UVW and RST and ...?
>
> "It wouldn't be a big deal for Emacs to have a default binding" - epitaph on a
> tombstone in Boot Hill, Tombstone, Arizona.
>

I'm neither for nor against this proposal anymore, but I'd like it if
we keep the discussion going, so here are my thoughts.

1. But there is a point to it! I may be wrong, but isn't M-f4 what
most desktop environments, e.g. KDE and Gnome, use to close a window
by default? To a new Emacs user, which we have to consider, M-f4 *not*
closing the window on a Windows system could potentially be confusing
and maybe even irritating. The new user maybe doesn't know that she
can make new key bindings herself and even if she knows she *can* make
new bindings, maybe she doesn't know what command to bind it to.
save-buffers-kill-terminal probably isn't what first comes to mind.

4. No one is saying we should bind M-f4 because it is unused. It's
just that it could have a very useful default binding for Windows
users which just happens to be unused today.

-- 
Deniz Dogan

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

[Stefan Monnier]

> I'm neither for nor against this proposal anymore, but I'd like it if
> we keep the discussion going, so here are my thoughts.

I don't really know what's the proposal anyway, so if someone can make
it clear, and with a clear justification, that would be helpful.

> 1. But there is a point to it! I may be wrong, but isn't M-f4 what
> most desktop environments, e.g. KDE and Gnome, use to close a window
> by default?

That's irrelevant: these bindings come from the UI environment (the
window-manager) and work regardless of what Emacs does (they send
a `delete' X11 event, IIRC, which Emacs handles properly by closing the
corresponding frame).
I.e. these bindings already work right in Gnome and KDE, without having
to bind M-f4 to anything inside Emacs.

> 4. No one is saying we should bind M-f4 because it is unused. It's
> just that it could have a very useful default binding for Windows
> users which just happens to be unused today.

Is M-f4 a standard binding in Windows, as it is in Gnome and KDE?
Does it normally do the same as in Gnome/KDE?
Does Emacs handle it correctly already by virtue of the key-binding
being caught before it is passed on to Emacs's usual key handling, just
as it happens in X11?


        Stefan

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

[Deniz Dogan]

2011/1/12 Stefan Monnier <monnier@iro.umontreal.ca>:
>> I'm neither for nor against this proposal anymore, but I'd like it if
>> we keep the discussion going, so here are my thoughts.
>
> I don't really know what's the proposal anyway, so if someone can make
> it clear, and with a clear justification, that would be helpful.
>

The proposal was to bind M-f4 to save-buffers-kill-terminal or a
similar function on Windows installations only.

>> 1. But there is a point to it! I may be wrong, but isn't M-f4 what
>> most desktop environments, e.g. KDE and Gnome, use to close a window
>> by default?
>
> That's irrelevant: these bindings come from the UI environment (the
> window-manager) and work regardless of what Emacs does (they send
> a `delete' X11 event, IIRC, which Emacs handles properly by closing the
> corresponding frame).
> I.e. these bindings already work right in Gnome and KDE, without having
> to bind M-f4 to anything inside Emacs.
>

Right, but M-f4 doesn't "work" in Windows for a reason that is beyond
me, but which some people on here seem to understand.

>> 4. No one is saying we should bind M-f4 because it is unused. It's
>> just that it could have a very useful default binding for Windows
>> users which just happens to be unused today.
>
> Is M-f4 a standard binding in Windows, as it is in Gnome and KDE?
> Does it normally do the same as in Gnome/KDE?
> Does Emacs handle it correctly already by virtue of the key-binding
> being caught before it is passed on to Emacs's usual key handling, just
> as it happens in X11?
>

M-f4 is a standard keybinding in Windows and it normally does the same
thing as it does in Gnome and KDE, which is close the active window or
exit the current application. The problem is that when I hit M-f4 in
*Emacs* running on Windows, Emacs says that the key is undefined and
that's the end of that.

This is where the idea of binding M-f4 in Emacs came up. Whether it's
a good one or a bad one, I don't know...

-- 
Deniz Dogan

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

[Stefan Monnier]

> The proposal was to bind M-f4 to save-buffers-kill-terminal or a
> similar function on Windows installations only.

I think handle-delete-frame would make more sense.

> M-f4 is a standard keybinding in Windows and it normally does the same
> thing as it does in Gnome and KDE, which is close the active window or
> exit the current application. The problem is that when I hit M-f4 in
> *Emacs* running on Windows, Emacs says that the key is undefined and
> that's the end of that.

> Right, but M-f4 doesn't "work" in Windows for a reason that is beyond
> me, but which some people on here seem to understand.

So now the question is indeed: how is M-f4's standard Windows behavior
of closing the window expected to be implemented?  Is it possible to
globally (well, except for Emacs ;-) change this key to some other one?

> This is where the idea of binding M-f4 in Emacs came up. Whether it's
> a good one or a bad one, I don't know...

Maybe binding it (in w32) to handle-delete-frame would be a good way to
implement the expected behavior, indeed.  But first, we need to know how
it's normally implemented in standard confirming applications.


        Stefan

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

[Óscar Fuentes]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

[snip]

>> This is where the idea of binding M-f4 in Emacs came up. Whether it's
>> a good one or a bad one, I don't know...
>
> Maybe binding it (in w32) to handle-delete-frame would be a good way to
> implement the expected behavior, indeed.  But first, we need to know how
> it's normally implemented in standard confirming applications.

When Alt-F4 is pressed, the event is sent to the application as any
other keypress. The application can handle the event as it pleases
(that's the case of Emacs) or delegate the handling of that event to
Windows, which performs standard actions for certain well-known
events. But please note that the event is sent to the application first
and the OS executes the standard associated action only when the
application delegates the event handling to it. This differs from KDE,
which handles Al-F4 and Emacs never sees it

This is the typical event loop of a Windows application (pseudocode):

switch(event) {
case foo: do_something(); break;
case bar: do_something_else(); break;
/* More case's for all events we are interested on */
...
/* Let Windows handle all the rest: */
default: let_Windows_process_it()
}

When Alt-F4 is delegated to Windows, it generates events for closing the
active window.

On Windows, if the Emacs system menu is activated (you click the icon
just above the File menu) it shows a standard entry "Close Alt-F4". But
then you press Alt-F4 and Emacs reports on the modeline "<M-f4> is
undefined".

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

[PJ Weisberg]

On Wed, Jan 12, 2011 at 7:59 PM, Óscar Fuentes <ofv@wanadoo.es> wrote:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
> This is the typical event loop of a Windows application (pseudocode):
>
> switch(event) {
> case foo: do_something(); break;
> case bar: do_something_else(); break;
> /* More case's for all events we are interested on */
> ...
> /* Let Windows handle all the rest: */
> default: let_Windows_process_it()
> }
>
> When Alt-F4 is delegated to Windows, it generates events for closing the
> active window.
>
> On Windows, if the Emacs system menu is activated (you click the icon
> just above the File menu) it shows a standard entry "Close Alt-F4". But
> then you press Alt-F4 and Emacs reports on the modeline "<M-f4> is
> undefined".

It sounds like the 'correct' thing to do is is to call
let_Windows_process_it() whenever any "<foo-key> is undefined" message
is reported.  The question of how difficult that would be to do is
another matter.

On Thu, Jan 13, 2011 at 2:18 PM, Drew Adams <drew.adams@oracle.com> wrote:

> If the latter (b) is the only reason, then I don't see that as a good reason to
> force the same restriction on Emacs when used with other window mgrs that do not
> grab it.  If Gnome and KDE forced Emacs to paint everything bright yellow, would
> we think it's appropriate to force the same thing on all other platforms?

If Emacs with the default configuration was bright yellow in Gnome and
KDE, and you installed it on some less well-supported platform with
the default configuration, wouldn't you expect it to be the same color
as it was in Gnome and KDE?  Especially since all the other
applications on this platform are also bright yellow, and the only
reason Emacs isn't is because of a slight hiccup in the paint-handling
code.

I don't think the argument that "if we bind <M-f4> to this function
now, we won't be able to bind it to something else later" holds up for
this key combination.  The author of some new whiz-bang-mode might
consider binding <M-f12> to whiz-bang-cool-new-function, but <M-f4> is
already so well-known as the "close this window" key that I don't
think you could seriously propose using it for anything else at this
point.

-PJ

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

[Stefan Monnier]

> It sounds like the 'correct' thing to do is is to call
> let_Windows_process_it() whenever any "<foo-key> is undefined" message
> is reported.

Yes, that's another way to attack the problem.  And it would make sense.

> The question of how difficult that would be to do is another matter.

Indeed, there are several potential difficulties:
- the time when "<foo-key> is undefined" is run can be much later than
  when we received the key event from Windows (some other events may
  have been received in the mean time already, for example), so that
  might cause extra difficulties.
- when we get to "<foo-key> is undefined", the event has been remapped
  a few times, so it can be far from obvious how to turn the resulting
  Elisp event and turn it back into its original Windows event (tho,
  we normally have access to the raw (un-remapped) Elisp event, so some
  of that work is done).

A simpler solution is to dump the problem onto the user: setup
a `w32-passthrough-events' where the user can specify events that should
be passed on to Windows's standard lib rather than handled by Emacs.
But it still leaves open the question whether it should contain M-f4 or
A-f4 (or use yet-another event representation), as well as what happens
when the user hits C-x M-f4.


        Stefan

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

[Lennart Borgman]

On Fri, Jan 14, 2011 at 4:48 PM, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:
>> It sounds like the 'correct' thing to do is is to call
>> let_Windows_process_it() whenever any "<foo-key> is undefined" message
>> is reported.
>
> Yes, that's another way to attack the problem.  And it would make sense.

I like this idea. It is platform independent and at the same time it
confirms to different platforms.


>> The question of how difficult that would be to do is another matter.
>
> Indeed, there are several potential difficulties:
> - the time when "<foo-key> is undefined" is run can be much later than
>  when we received the key event from Windows (some other events may
>  have been received in the mean time already, for example), so that
>  might cause extra difficulties.
> - when we get to "<foo-key> is undefined", the event has been remapped
>  a few times, so it can be far from obvious how to turn the resulting
>  Elisp event and turn it back into its original Windows event (tho,
>  we normally have access to the raw (un-remapped) Elisp event, so some
>  of that work is done).

We would need the original input event at the right level of the w32
event loop. Do you mean we have that?

If that can be handled I think it could be the best solution.

However simulating input events to the w32 message loop can be a bit
tricky perhaps. (But do not ask me about details right now.)

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

[Drew Adams]

> >> It sounds like the 'correct' thing to do is is to call
> >> let_Windows_process_it() whenever any "<foo-key> is 
> >> undefined" message is reported.
> >
> > Yes, that's another way to attack the problem.  And it 
> > would make sense.
> 
> I like this idea. It is platform independent and at the same time it
> confirms to different platforms.

Doesn't sound like a good idea.  Lisp code should be able to check whether a
given key is bound and do something if not (e.g. condition-case check for
unbound error).

Dunno whether that C-code change would prevent checking whether it was bound
(hope not), but it sounds like hitting the key would automatically go to Windows
if not bound in Emacs.

I'm not claiming that's the case; just raising the question.

The best approach, regardless what default behavior is decided on (and I prefer
it to be unbound), is to let the user decide.  IOW Stefan's suggestion of
`w32-passthrough-events' (or at least `w32-register-hot-key').

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

[Lennart Borgman]

On Mon, Jan 17, 2011 at 2:40 AM, Drew Adams <drew.adams@oracle.com> wrote:
>> >
>> > Doesn't sound like a good idea.  Lisp code should be able
>> > to check whether a given key is bound and do something if
>> > not (e.g. condition-case check for unbound error).
>>
>> A good point. However the possibility to check whether a key is
>> unbound in Emacs will not be affected.
>
> Really?  Good, in that case.  I was under the impression that simply hitting the
> key would mean that Windows grabs it.

Yes, of course. What else should it do?


> Admittedly, it is not everyday that code wants to handle an unbound key when it
> is pressed.  Of course, that's exactly the case of the proposal...  What we
> would be doing in effect is reserving that possibility for Window/Gnome/KDE to
> handle Alt-f4, hardcoding it instead of letting anyone code it for any purpose.
> But I do recognize that this is not a big use case.

No one has suggested that Alt+F4 should be hardcoded to be sent to w32.

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

[Drew Adams]

> > Really?  Good, in that case.  I was under the impression 
> > that simply hitting the key would mean that Windows grabs it.
> 
> Yes, of course. What else should it do?

There are 3 possibilities that have been discussed:
1. It is bound in Emacs. Invoke the Emacs binding.
2. It is not bound.  Raise an Emacs unbound error.
3. It is not bound.  Pass Alt-F4 through to Windows.

No one has disagreed about #1.  You think that #3 is always preferable to #2 and
should become hard-coded behavior.  I think that the choice between #2 and #3
should be up to the user and Emacs libraries if possible.

> No one has suggested that Alt+F4 should be hardcoded to be 
> sent to w32.

Odd that you would say this just after you asked what other behavior could
possibly exist.

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

[Lennart Borgman]

On Mon, Jan 17, 2011 at 7:22 PM, Drew Adams <drew.adams@oracle.com> wrote:
>> > Really?  Good, in that case.  I was under the impression
>> > that simply hitting the key would mean that Windows grabs it.
>>
>> Yes, of course. What else should it do?
>
> There are 3 possibilities that have been discussed:
> 1. It is bound in Emacs. Invoke the Emacs binding.
> 2. It is not bound.  Raise an Emacs unbound error.
> 3. It is not bound.  Pass Alt-F4 through to Windows.
>
> No one has disagreed about #1.  You think that #3 is always preferable to #2 and
> should become hard-coded behavior.

Yes, I actually do prefer #3 hard-coded instead of #2.

I would be glad if you instead of writing a lot of things clearly told
why you prefer #2 hard-coded.


> I think that the choice between #2 and #3
> should be up to the user and Emacs libraries if possible.

I can't see how both users and libraries could decide on this. If such
a choice is given it must be up to the user to decide. (I have nothing
particular against such a choice, but I can't really see the merit of
it either.)

>> No one has suggested that Alt+F4 should be hardcoded to be
>> sent to w32.
>
> Odd that you would say this just after you asked what other behavior could
> possibly exist.

Could you please be a bit more exact in your questions? We can have
more fun than arguing like this.

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

[Drew Adams]

> > There are 3 possibilities that have been discussed:
> > 1. It is bound in Emacs. Invoke the Emacs binding.
> > 2. It is not bound.  Raise an Emacs unbound error.
> > 3. It is not bound.  Pass Alt-F4 through to Windows.
> >
> > No one has disagreed about #1.  You think that #3 is always 
> > preferable to #2 and should become hard-coded behavior.
> 
> Yes, I actually do prefer #3 hard-coded instead of #2.
> 
> I would be glad if you instead of writing a lot of things clearly told
> why you prefer #2 hard-coded.

I do not prefer #2 hard-coded.  I don't want either #2 or #3 hard-coded.  That
should be clear.

I don't want us to choose for the users which it should be.  I want to let users
and libraries decide what the behavior of Alt-f4 should be: let them choose #1,
#2, or #3.  Why not?

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

> > I think that the choice between #2 and #3
> > should be up to the user and Emacs libraries if possible.
> 
> I can't see how both users and libraries could decide on this.

So far it seems to have been agreed that in any case (whatever is done or not
done) both users and libraries should feel free to bind M-f4 in Emacs.

How can both decide that?  Well how do they, today?  When you answer that you've
also answered your question to me about deciding #2 vs #3.

IOW, if either a user or a library can bind M-f4, then either should also be
able to decide what happens if M-f4 is invoked when unbound.  An optional
library is just an extension of a user: loading it and activating some of its
features is a user choice.

> I have nothing particular against such a choice [#2]

Great, then we can agree on it.

> but I can't really see the merit of it either.

The merit: More say (more control) by Emacs users, including Lispers, over their
Emacs experience.  Later binding: decide at user config time or run time, not at
emacs-devel@gnu.org design time.

> >> No one has suggested that Alt+F4 should be hardcoded to be
> >> sent to w32.
> >
> > Odd that you would say this just after you asked what other 
> > behavior could possibly exist.
> 
> Could you please be a bit more exact in your questions?

See what you wrote at the top.  You've made it very clear that you want Alt+f4
hard-coded to pass through to Windows when unbound in Emacs.

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.