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

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?

[Christopher Allan Webber]

Yes, that is common, but it is usually window managers who handle that
key.

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

[Lennart Borgman]

On Mon, Jan 10, 2011 at 2:01 AM, Drew Adams <drew.adams@oracle.com> wrote:
>> 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.


Yes, I think have with references to the documentation on ms site.
(But don't ask me where, it was quite a while ago.)

> 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 must say I am surprised that it seems to work, at least sometimes.
It is not guaranteed to work, but it might work much more often than I
expect. However try this procedure:

   emacs -Q
   M-e:   (w32-register-hot-key [M-tab])
   f1-c M-tab

This starts the windows Alt-Tab application switching.

Now go back to the Emacs instance and try "f1-c M-tab" again. Now it works.

Something seems out of order here, but you are anyway right in that it
kind of works and probably is useful. But it is not guaranteed to
work.

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

[Drew Adams]

> I must say I am surprised that it seems to work, at least sometimes.
> It is not guaranteed to work, but it might work much more often than I
> expect. However try this procedure:
> 
>    emacs -Q
>    M-e:   (w32-register-hot-key [M-tab])
>    f1-c M-tab
>
> This starts the windows Alt-Tab application switching.
> Now go back to the Emacs instance and try "f1-c M-tab" again. 
> Now it works.

(I assume you meant `M-:', not `M-e:'.)

Maybe someone can give a good reason why it doesn't work the first time.  If
not, please file a bug.

Note that this use of `M-tab' is a bit special: you are not invoking it, you are
asking about the binding.  That might have something to do with the problem
here.  I have never had Windows app switching get activated when I have invoked
`M-tab'.

> Something seems out of order here, but you are anyway right in that it
> kind of works and probably is useful. But it is not guaranteed to
> work.

Little in this world is guaranteed to work.

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

[Lennart Borgman]

On Mon, Jan 10, 2011 at 4:01 AM, Drew Adams <drew.adams@oracle.com> wrote:
>> I must say I am surprised that it seems to work, at least sometimes.
>> It is not guaranteed to work, but it might work much more often than I
>> expect. However try this procedure:
>>
>>    emacs -Q
>>    M-e:   (w32-register-hot-key [M-tab])
>>    f1-c M-tab
>>
>> This starts the windows Alt-Tab application switching.
>> Now go back to the Emacs instance and try "f1-c M-tab" again.
>> Now it works.
>
> (I assume you meant `M-:', not `M-e:'.)
>
> Maybe someone can give a good reason why it doesn't work the first time.  If
> not, please file a bug.

I have already given the explanation and I think I have filed a bug
report long ago concerning this so I think there is nothing to do on
my side.

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

[Dimitri Fontaine]

Lennart Borgman <lennart.borgman@gmail.com> writes:
> 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.)

If you're using a qwerty keyboard you can use C-[ C-i to achieve M-TAB.

Regards,
-- 
dim

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?

[Drew Adams]

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

Same argument for all of the other Windows keys:

http://support.microsoft.com/kb/126449
http://www.autohotkey.com/wiki/index.php?title=Standard_Windows_Hotkeys
http://www.techpraveen.com/2008/08/keyboard-shortcuts-for-windows.html

There are no doubt similar keys for KDE, Gnome etc.
Or you could argue for keeping just the common subset.

Where do you draw the line?  I would draw it right here and now: let's not bind
_any_ such keys in Emacs by default.  There's already enough dispute between
Emacs and window managers over keys such as ALT-TAB (hello, Lennart).

I do think we should make it easy (and clear how) to choose whether to give all
power to the window manager or all (almost) to Emacs.  Maybe we do that well
enough already - dunno.

I'm more interested in Emacs newbies learning an Emacs key such as `C-x 5 0' to
remove a frame than I am in reproducing a window-mgr key that does essentially
the same thing (perhaps at a different level).  You seem to be more worried
about keeping newbies warm and comfortable with what they are already used to.
The bike shed is blue.

Also, we already discussed letting Emacs users use menu accelerator keys, so
that they could do what is in all of the menus using the keyboard (without tmm,
lacarte, etc.).  That, IMO, is a better approach to the current question.  It
should be enough to help newbies along by providing menu acceleration.  We
should not need to provide all of the window-mgr keys they are used to, by
default.

(Yes, I realize (a) that these are different things and (b) that the user still
needs to find `Delete Frame' or `Quit' in the Emacs `File' menu.)

Not to mention that Windows newbies still have the little window-mgr menu from
the upper left of the title bar (whatever it's called) to do things like close a
window-mgr window.  How much do we need to reproduce the outside-Emacs
environment for Emacs newbies?  There are enough ways to delete a window-mgr
window.

Just one opinion.

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

Emacs is a dish you learn to appreciate.  MacDo it isn't.  There is no royal or
fast-food road to fine cuisine, fine music, or anything else rich and deep.

> save-buffers-kill-terminal probably isn't what first comes to mind.

Gee, and I thought that Alt-f4 just deleted the window.  Or do you want a
Windows (KDE, Gnome) key for closing/killing the app as well?

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

OK, good.  But there are plenty more "very useful default bindings for Windows
users".  You give Johnny this one by default and he thinks it's unfair that you
don't also give him that one.  And he's got a point there...

That's the way Johnny is (like the rest of us).  Better he should learn Emacs.

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

[Chad Brown]

Since we've admitted that we're bikeshedding...

On Jan 12, 2011, at 9:17 AM, Drew Adams wrote:
> Same argument for all of the other Windows keys:

Either this is an argument on principles, or a cost/benefit trade-off.
Mr. Dogan is clearly talking about the cost/benefit trade-off based on
usability and opportunity cost.  Mr. Adams is trying to make an
argument on principle.

The problem with Mr. Adams' argument is that it applies *at least* as
strongly against any sort of Emacs on Windows, at all.  For example:

> Emacs is a dish you learn to appreciate.  MacDo it isn't.  There is no royal or
> fast-food road to fine cuisine, fine music, or anything else rich and deep.

Since you're talking about Emacs on Windows, you're *already* standing
inside the `MacDo'.  You're not talking about fine cuisine or freedom;
you're debating whether to order from the bargain menu or splurge on
the Big Mac.

>> 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.
> 
> OK, good.  But there are plenty more "very useful default bindings for Windows
> users".  You give Johnny this one by default and he thinks it's unfair that you
> don't also give him that one.  And he's got a point there...

That sounds like a perfectly good time to teach Johnny the lesson that
you arbitrarily assert should only be taught one `step' earlier.  By
your argument, however, we should be teaching Johnny to avoid Windows
altogether.

*Chad

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?

[Lennart Borgman]

On Thu, Jan 13, 2011 at 3:42 AM, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:
>> 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.


On the page Drew mentioned, http://support.microsoft.com/kb/126449, it says

  Windows system key combinations
  - ALT+F4: Quit program


A couple of things to notice:
  - It looks like the window manager could handle this (but Emacs
bypasses that).
  - It is not M-f4 it is Alt+F4 which is very different.


> Maybe binding it (in w32) to handle-delete-frame would be a good way to
> implement the expected behavior, indeed.

Then bind A-f4.


>  But first, we need to know how
> it's normally implemented in standard confirming applications.

See above.

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?

[Lennart Borgman]

On Thu, Jan 13, 2011 at 4:59 AM, Óscar Fuentes <ofv@wanadoo.es> wrote:
>
> 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.

Good points, but did you verify that it generates an event for closing
the active window (and not for quitting the application as the doc at
MS seems to suggest)?

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

[Óscar Fuentes]

Lennart Borgman <lennart.borgman@gmail.com> writes:

>> When Alt-F4 is delegated to Windows, it generates events for closing the
>> active window.
>
> Good points, but did you verify that it generates an event for closing
> the active window (and not for quitting the application as the doc at
> MS seems to suggest)?

The default behavior for Alt-F4 is to generate a WM_CLOSE message that
is sent to the active window. The usual reaction is to destroy the
window, which means that if we are dealing with the application's main
window the application is terminated as well. WM_CLOSE is generated too
by the "Close" button on the top left corner of the window. Emacs
handles WM_CLOSE in w32term.c around line 4700. Emacs behaves as
described above: kills the current frame.

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

[Stefan Monnier]

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

Thanks.  So the right thing to do here is to change Emacs so it delegates
the Alt-F4 to the standard Windows routine that turns it into a WM_CLOSE.
Patch welcome,


        Stefan

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

[Óscar Fuentes]

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

>> When Alt-F4 is delegated to Windows, it generates events for closing the
>> active window.
>
> Thanks.  So the right thing to do here is to change Emacs so it delegates
> the Alt-F4 to the standard Windows routine that turns it into a WM_CLOSE.
> Patch welcome,

Binding Alt-F4 to a function such as handle-delete-frame will do
fine. That's far easier than dealing with the Windows API from the C
sources.

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

[Stefan Monnier]

>>> When Alt-F4 is delegated to Windows, it generates events for closing the
>>> active window.
>> Thanks.  So the right thing to do here is to change Emacs so it delegates
>> the Alt-F4 to the standard Windows routine that turns it into a WM_CLOSE.
>> Patch welcome,
> Binding Alt-F4 to a function such as handle-delete-frame will do
> fine. That's far easier than dealing with the Windows API from the C
> sources.

It's likely to end up approximating the right behavior, and lead to
more reports.  E.g. should it bind A-f4 or M-f4?


        Stefan

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

[Lennart Borgman]

On Thu, Jan 13, 2011 at 10:15 PM, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:
>>>> When Alt-F4 is delegated to Windows, it generates events for closing the
>>>> active window.
>>> Thanks.  So the right thing to do here is to change Emacs so it delegates
>>> the Alt-F4 to the standard Windows routine that turns it into a WM_CLOSE.
>>> Patch welcome,
>> Binding Alt-F4 to a function such as handle-delete-frame will do
>> fine. That's far easier than dealing with the Windows API from the C
>> sources.
>
> It's likely to end up approximating the right behavior, and lead to
> more reports.  E.g. should it bind A-f4 or M-f4?


To delegate Alt-F4 to Windows standard routine we have to catch it in
the message loop. I can't remember how it shows up in the message
loop. Does it come in one peace (i.e. Alt+F4) or in a sequence (i.e.
Alt and then F4)?

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

[Drew Adams]

What is the reason for Emacs to bind Alt-f4 (or M-f4) to behavior that agrees
with what Alt-f4 does outside Emacs?

Is the reason for this (a) user convenience?  Or is it (b) because with some
window mgrs we _cannot_ do otherwise (they always grab Alt-f4)?

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 the reason is instead for user convenience (a), so the same key does the same
thing inside and outside Emacs, then why stop with this key?  There are lots and
lots of other window-mgr keys that we could force upon Emacs as default bindings
- for similar "user convenience".  Shall we do them all?

Emacs already has its own keys to delete frames and kill Emacs.  Unless the
window mgr forces Alt-f4 upon Emacs, so there is no alternative, I don't see why
we should create a default binding in Emacs to match the window-mgr binding.

Just what is the real rationale behind this move?  Let's be clear, please.

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

[Lennart Borgman]

On Thu, Jan 13, 2011 at 11:18 PM, Drew Adams <drew.adams@oracle.com> wrote:
>
> Just what is the real rationale behind this move?  Let's be clear, please.


Would it be enough to say that the in the system menu there is an entry

   "Close Alt+F4"

but it does not work now because Emacs breaks it?

What do you believe a new user thinks when (s)he sees this?

And regarding your effort to try to stop this: In the long run I
believe we must change the key bindings. Or die.

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

[Drew Adams]

> > Just what is the real rationale behind this move?  Let's be 
> > clear, please.
> 
> Would it be enough to say that the in the system menu there 
> is an entry "Close Alt+F4" but it does not work now because
> Emacs breaks it?

Is it enough for you?  Not for me.  Emacs "breaks" lots of MS Windows keys, and
I generally don't lose much sleep over it (Zzzzzzzzzz).

What if a different window mgr does not use that key for `Close'?  Do we not
make it the Emacs default for that platform?  Do we instead bind that platform's
`Close' key by default there?

Do we limit this exercise to just the keys that _all_ window mgrs have in
common?  Or do we try to adapt Emacs to each window mgr separately, for each of
its own keys?

You've said that for you the criterion is simply that MS Windows has this `Close
Alt-F4' item in a system menu.  So that's neither exactly the (a) nor the (b)
that I mentioned: neither for user convenience nor because we cannot do
otherwise.

Fair enough, but I wonder if presence-in-a-system-menu is the consensus
rationale.  It's good to know why we're doing this.

> What do you believe a new user thinks when (s)he sees this?

How is this different from the umpteen other window-mgr keys?  Shall we add them
all as Emacs defaults?  If not, what do you believe a new user will think when
s?he tries them?

> And regarding your effort to try to stop this: In the long run I
> believe we must change the key bindings.  Or die.

Or die?  Lennart, please.

But yes, in the long run, we will die.
Even if we change the key bindings, alas.

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

[Stuart Hacking]

On 13 January 2011 22:18, Drew Adams <drew.adams@oracle.com> wrote:
> What is the reason for Emacs to bind Alt-f4 (or M-f4) to behavior that agrees
> with what Alt-f4 does outside Emacs?
>
> Is the reason for this (a) user convenience?  Or is it (b) because with some
> window mgrs we _cannot_ do otherwise (they always grab Alt-f4)?
>
> 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 [Alt-F4] quits Emacs in Gnome and KDE then one would expect the
same behaviour in Windows. This is from a user experience point of
view, regardless of whether the event is caught before or after Emacs
sees it. A user unfamiliar with Emacs will go for what they know, and
when it doesn't work they'll go straight back to vim. Is that what you
want? Misery and Suffering? ;-)

> If the reason is instead for user convenience (a), so the same key does the same
> thing inside and outside Emacs, then why stop with this key?  There are lots and
> lots of other window-mgr keys that we could force upon Emacs as default bindings
> - for similar "user convenience".  Shall we do them all?

I don't think it's necessary to implement every default keybinding,
but I think [Alt-F4] has become established enough that it's
worthwhile. Will CUA mode bind things like [Alt-F4]? I have never used
it - Perhaps CUA mode should be used for all of these general purpose
shortcuts?

Personally, I think b) provides a good enough reason: To try and
maintain behavioural consistency across platforms.

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

[Óscar Fuentes]

"Drew Adams" <drew.adams@oracle.com> writes:

>> > Just what is the real rationale behind this move?  Let's be 
>> > clear, please.
>> 
>> Would it be enough to say that the in the system menu there 
>> is an entry "Close Alt+F4" but it does not work now because
>> Emacs breaks it?
>
> Is it enough for you?  Not for me.  Emacs "breaks" lots of MS Windows keys, and
> I generally don't lose much sleep over it (Zzzzzzzzzz).

Are those other keys listed as accelerators on menu entries? Are those
used since Windows 3.0 (AFAIK) and thus firmly ingrained in the muscle
memory of die-hard Windows users? How much of those keys correspond to
operations as common as closing windows?

Using Alt-F4 instead of the mouse or M-x <whatever> for killing the
current frame is quite convenient, IMO.

> What if a different window mgr does not use that key for `Close'?  Do we not
> make it the Emacs default for that platform?  Do we instead bind that platform's
> `Close' key by default there?

First, we are talking about Windows here. Second, on at least one
popular window mngr (KDE) Emacs does not know which key is used for
closing the window. Nor it has any saying when the user presses the
key. On KDE that key is configurable. So discussing what other window
managers do is pretty irrelevant. We are talking about Emacs not
following a commonly used convention on certain environment.

[snip]

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

[Lennart Borgman]

On Thu, Jan 13, 2011 at 11:53 PM, Stuart Hacking <stuhacking@gmail.com> wrote:
>
> I don't think it's necessary to implement every default keybinding,
> but I think [Alt-F4] has become established enough that it's
> worthwhile. Will CUA mode bind things like [Alt-F4]? I have never used
> it - Perhaps CUA mode should be used for all of these general purpose
> shortcuts?

Alt+F4 is not part of CUA so cua-mode does not bind. cua-mode is
cross-platform, while Alt+F4 is w32 specific.

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

[Lennart Borgman]

On Thu, Jan 13, 2011 at 11:47 PM, Drew Adams <drew.adams@oracle.com> wrote:
>
> You've said that for you the criterion is simply that MS Windows has this `Close
> Alt-F4' item in a system menu.

It is the menu for Emacs.

> How is this different from the umpteen other window-mgr keys?

What ms doc says. How ingrained in muscle memory they are. How common
they are in other apps.

Maybe we have to be a bit specific. What other keys?

> Or die?  Lennart, please.

I am just trying to maintain the balanced tone in the arguments. ;-)

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

[Jason Rumney]

On 14/01/2011 06:00, Lennart Borgman wrote:
> To delegate Alt-F4 to Windows standard routine we have to catch it in
> the message loop. I can't remember how it shows up in the message
> loop. Does it come in one peace (i.e. Alt+F4) or in a sequence (i.e.
> Alt and then F4)?
>    

It comes in peace, as one piece.

More specifically the events should come as the following sequence:

Alt Down
F4 Down with Alt modifier set
F4 Up with Alt modifier set
Alt Up

If the second event is passed to Windows to handle, I suspect the third 
event may not arrive to Emacs.

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

[Jason Rumney]

On 14/01/2011 06:18, Drew Adams wrote:
> What is the reason for Emacs to bind Alt-f4 (or M-f4) to behavior that agrees
> with what Alt-f4 does outside Emacs?
>    

It is otherwise unbound.

> 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

In what way is an extra default keybinding a restriction?

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

[Lennart Borgman]

On Fri, Jan 14, 2011 at 1:12 AM, Jason Rumney <jasonr@gnu.org> wrote:
> On 14/01/2011 06:00, Lennart Borgman wrote:
>>
>> To delegate Alt-F4 to Windows standard routine we have to catch it in
>> the message loop. I can't remember how it shows up in the message
>> loop. Does it come in one peace (i.e. Alt+F4) or in a sequence (i.e.
>> Alt and then F4)?
>>
>
> It comes in peace, as one piece.

;-)

I thought I had left that habit of mispelling... - Some day I will
learn reading.

> More specifically the events should come as the following sequence:
>
> Alt Down
> F4 Down with Alt modifier set
> F4 Up with Alt modifier set
> Alt Up
>
> If the second event is passed to Windows to handle, I suspect the third
> event may not arrive to Emacs.

Is then all we have to do pass the second event to Windows?

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

[Drew Adams]

> > What is the reason for Emacs to bind Alt-f4 (or M-f4) to 
> > behavior that agrees with what Alt-f4 does outside Emacs?
> 
> It is otherwise unbound.

That's the reason?  It doesn't have a default binding so it needs one?  And that
default binding should be `Alt-4'?

> > 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
> 
> In what way is an extra default keybinding a restriction?

So let's bind _all_ unbound keys by default, then.
Hey, that's no restriction.  What's the harm?

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

[Jason Rumney]

On 14/01/2011 08:21, Lennart Borgman wrote:
>
>> More specifically the events should come as the following sequence:
>>
>> Alt Down
>> F4 Down with Alt modifier set
>> F4 Up with Alt modifier set
>> Alt Up
>>
>> If the second event is passed to Windows to handle, I suspect the third
>> event may not arrive to Emacs.
>>      
> Is then all we have to do pass the second event to Windows?
>    

That is the easy part. The more difficult part is checking whether the 
key is bound in Emacs first.  Does your low level keyboard hook patch 
already do something like this? Otherwise adding a default binding on 
Windows only to send the SC_CLOSE system event is another way of 
handling it that is closer to the system behaviour than the alternative 
bindings that have been suggested here.

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

[Jason Rumney]

On 14/01/2011 09:35, Drew Adams wrote:
> So let's bind _all_ unbound keys by default, then.
> Hey, that's no restriction.  What's the harm?
>    

Please take your straw men elsewhere.

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

[Lennart Borgman]

On Fri, Jan 14, 2011 at 6:02 AM, Jason Rumney <jasonr@gnu.org> wrote:
> On 14/01/2011 08:21, Lennart Borgman wrote:
>>
>>> More specifically the events should come as the following sequence:
>>>
>>> Alt Down
>>> F4 Down with Alt modifier set
>>> F4 Up with Alt modifier set
>>> Alt Up
>>>
>>> If the second event is passed to Windows to handle, I suspect the third
>>> event may not arrive to Emacs.
>>>
>>
>> Is then all we have to do pass the second event to Windows?
>>
>
> That is the easy part.

Yes. If you know that is what you should do ;-)

> The more difficult part is checking whether the key
> is bound in Emacs first.  Does your low level keyboard hook patch already do
> something like this?

No, it doesn't implement any support for this and I do not think it is
the right level since it is working on a lower level, before the
message loop and does not have all the required information collected
AFAICS (but I might be missing something). The only purpose of it is
to prevent Windows from handling certain keys that you cannot prevent
it to handle other ways. See this link (which does not tell everything
about LowLevelKeyboardProc however):

  http://msdn.microsoft.com/en-us/library/ms644985(v=vs.85).aspx

But Emacs message loop (not the w32 level) does collect info about key
sequences available. Can't that info be transferred and used for the
w32 level message loop as grishka suggested?
> Otherwise adding a default binding on Windows only to
> send the SC_CLOSE system event is another way of handling it that is closer
> to the system behaviour than the alternative bindings that have been
> suggested here.
>
>

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

[Giorgos Keramidas]

On Thu, 13 Jan 2011 14:47:28 -0800, "Drew Adams" <drew.adams@oracle.com> wrote:
> What if a different window mgr does not use that key for `Close'?  Do
> we not make it the Emacs default for that platform?  Do we instead
> bind that platform's `Close' key by default there?

We don't have to look very far into the future for this, or to very
exotic window managers.  My current window manager is 'awesome', and its
key bindings are *all* tunable through Lua code.  The setup I use now
binds <win - f4> to the `kill-client' event (where <win> is the key to
the left of <left_alt>.  In this setup there's also another tiny nit
that affects what <alt-f4> means: <alt> is always passed to the X11
client frame as <meta>.

I also don't see why Emacs should start binding <alt-f4> or <win-f4> or
any other key some window manager _may_ bind.

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

[Lennart Borgman]

On Fri, Jan 14, 2011 at 10:25 AM, Giorgos Keramidas
<keramida@ceid.upatras.gr> wrote:
>
> We don't have to look very far into the future for this, or to very
> exotic window managers.  My current window manager is 'awesome', and its
> key bindings are *all* tunable through Lua code.

Interesting, but probably not mainstream. Rather prepackaging seems to be that.

> I also don't see why Emacs should start binding <alt-f4> or <win-f4> or
> any other key some window manager _may_ bind.

Isn't the problem the reverse? Emacs is currently (at least on w32) by
default binding Alt+F4 (but not using it) which prevents the window
manager from doing its default action (and also presents bad info to
the user).

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?

[Lennart Borgman]

On Fri, Jan 14, 2011 at 11:49 AM, PJ Weisberg
<pj@irregularexpressions.net> wrote:
>  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.

Maybe. But most people use Alt+F4 for this ;-)

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?

[Drew Adams]

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

AFAICT no one has argued that.  Certainly not I.

I mainly _asked_ what our reasons are for binding it.  (And the reasons given
have varied, BTW.)  AFAICT, we have not concluded _why_ we should do it, even if
some people are definitely in favor of doing it.

If we do this kind of thing it is good to know why, especially because we will
no doubt be having this same conversation again someday about some other outside
hotkey.


To the extent that I do argue against Emacs binding this key by default
(actually, I don't feel super strongly about it, it's just that the reasons in
favor have so far been so weak), my arguments are these:

1. Alt-f4 (or `M-f4') is an _easily repeatable chord_.  Unlike `C-x 5 0' or `C-x
C-c', you can repeat it by just holding it down.  Such keys are valuable - for
use in Emacs.  By users.  By Emacs libraries.  Finding such keys that are not
already bound or reserved or in some other way "taken" is getting harder.

I do not like for Emacs to gratuitously "waste" keys.  And this particular waste
seems pretty darn gratuitous to me, which is why I asked for the reasons behind
it.


2. Giving a default binding to this key will (yes, it seems to) discourage other
uses of it in Emacs.  Over time, default bindings sometimes become sacrosanct.

We have not even bound this key yet, but already the conversation is getting
overtones of gotta-have-it-and-respect-it-because-it-is-standard-out-there.
(See the end of this mail, for example.)

Slippery slope.  It won't be long before someone will complain that library
Foobar stomped on `M-f4', the universally recognized standard compulsory model
key for deleting a window and quitting an app.


3. Emacs has its own bindings and its own logic for key bindings.  We already
have keys to delete a frame and quit Emacs.

And, BTW, we do not waste repeatable keys/chords for that: `C-x 5 0' and `C-x
C-c' are not large sacrifices to these actions that are _not_ often repeated
consecutively (yes, if delete-frame had a repeatable key you could hold it down
to delete multiple frames in a flurry, but that is a negligible use case).

`M-f4', however, _would_ sacrifice a simple, repeatable key for an action that
is essentially not repeatable - a waste.


4. The argument that just _because_ a key is unbound we _should_ give it a
default binding is a non-starter, in my book.  Do I really need to explain why?

But that argument was actually advanced, and in just that arbitrary form:
_Because_ "it is otherwise unbound".  Since unspecific, that applies to all
unbound keys: we should bind them all by default?

Mallory might have climbed Everest "because it's there", but that should not be
why we make key bindings.  You cannot find a more gratuitous waste than such an
approach.


5. The argument that a key that is unbound might as well get a default binding
that fits the world outside Emacs begs the questions: which worlds (platforms)?
Which keys in that category - all of them?  And what about existing Emacs
bindings that already conflict with the outside world?


6. The strongest argument so far in favor of this binding, IMO, is the argument
that many, many users are already used to this key.

But it doesn't convince me, personally.  I would rather that we leave this key
unbound, so Emacs users and libraries do not hesitate (yes, some would) to put
it to good (better) use inside Emacs, in particular exploiting its property of
easy repetition in some way (e.g., for any repetitive or incremental action).


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

See #1 and #2 above.  It's happening already: "So well-known" trumps being able
to put it to better use _within and for_ Emacs.

Poor Emacs.

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

[Lennart Borgman]

On Fri, Jan 14, 2011 at 6:58 PM, Drew Adams <drew.adams@oracle.com> wrote:
>> 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.
>
> AFAICT no one has argued that.  Certainly not I.
>
> I mainly _asked_ what our reasons are for binding it.  (And the reasons given
> have varied, BTW.)  AFAICT, we have not concluded _why_ we should do it, even if
> some people are definitely in favor of doing it.
>
> If we do this kind of thing it is good to know why, especially because we will
> no doubt be having this same conversation again someday about some other outside
> hotkey.
>
>
> To the extent that I do argue against Emacs binding this key by default
> (actually, I don't feel super strongly about it, it's just that the reasons in
> favor have so far been so weak), my arguments are these:
>
> 1. Alt-f4 (or `M-f4') is an _easily repeatable chord_.  Unlike `C-x 5 0' or `C-x
> C-c', you can repeat it by just holding it down.  Such keys are valuable - for
> use in Emacs.  By users.  By Emacs libraries.  Finding such keys that are not
> already bound or reserved or in some other way "taken" is getting harder.
>
> I do not like for Emacs to gratuitously "waste" keys.  And this particular waste
> seems pretty darn gratuitous to me, which is why I asked for the reasons behind
> it.
>
>
> 2. Giving a default binding to this key will (yes, it seems to) discourage other
> uses of it in Emacs.  Over time, default bindings sometimes become sacrosanct.

As I have already said (but you might have missed) Emacs does bind
Alt+F4 by default now (but does not use it). Aren't you from that
perspective actually kind of defending that binding?

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

[Drew Adams]

> > 2. Giving a default binding to this key will (yes, it seems 
> > to) discourage other uses of it in Emacs.  Over time, default
> > bindings sometimes become sacrosanct.
> 
> As I have already said (but you might have missed) Emacs does bind
> Alt+F4 by default now (but does not use it). Aren't you from that
> perspective actually kind of defending that binding?

To the extent that I am arguing against Emacs binding M-f4 and not just _asking
why_ we should bind it:

1. No, I was not aware that it is already bound by default but that binding does
not work.  (I guess that's what you are saying.)  Just what do you mean by that?
On Windows: `C-h k M-<f4>' => "<M-f4> is undefined" (and the key does not appear
in the `global-map', at least).

2. Whether the Emacs binding already exists (but doesn't work) or not, I have
exactly the same arguments against it.  (And I have the same question wrt the
supporting arguments: where's the beef?)

Again, I do not feel super strongly about not binding this key by default.  But
I think that the arguments presented in support of this binding, so far at
least, are pretty weak.

---

[Note too that I would not mind our revisiting some other default bindings that
are not so wise.

Example: Bindings `f3' for `kmacro-start-macro-and-insert-counter' and `f4' for
`kmacro-end-or-call-macro' would be better moved to _non-repeating keys_, and
preferably a pair of keys that looks like a pair.  The keys chosen back in the
dark ages for `kmacro-start' and `kmacro-end' (actually, for their ancestors)
are `C-x (' and `C-x )'.

Those older keys have the twin advantages of (a) not being (hence not wasting)
repeating keys and (b) employing start and end parens as mnemonic devices.
Clearly there was much more thought given to choosing `C-x (' and `C-x )', many
moon ago, than there was given more recently to choosing `f3' and `f4'.  It
seems like someone just noticed one day that up through Emacs 22 the keys `f3'
and `f4' were left unbound and exclaimed "Eureka! Why not waste 'em
gratuitously? They're not doing anyone any good being unbound!"

And so on - there are other bindings that are also not so wise.  Too often I
think we have taken the lazy route as time goes on: an unbound key is discovered
and adopted with little thought.  Hence my bringing up the question this time:
_why_ this binding?  Let the good answers come...]

---

(FWIW, looking at some old mail messages I came across this in
`xterm-alternatives-map' (I don't have xterm.el, so I cannot check that it was
actually implemented): [A-f4] seems to act there as [f52].  What to do about
that, for those who want Emacs to respect `ALT-f4' in the wider world?  Perhaps
you agree that libraries can bind it, but doesn't that interfere with users who
expect it to do its extra-emacs thing?)

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

[Lennart Borgman]

On Fri, Jan 14, 2011 at 11:24 PM, Drew Adams <drew.adams@oracle.com> wrote:
>> > 2. Giving a default binding to this key will (yes, it seems
>> > to) discourage other uses of it in Emacs.  Over time, default
>> > bindings sometimes become sacrosanct.
>>
>> As I have already said (but you might have missed) Emacs does bind
>> Alt+F4 by default now (but does not use it). Aren't you from that
>> perspective actually kind of defending that binding?
>
> To the extent that I am arguing against Emacs binding M-f4 and not just _asking
> why_ we should bind it:

This is not about M-f4, it is about A-f4.

> 1. No, I was not aware that it is already bound by default but that binding does
> not work.  (I guess that's what you are saying.)  Just what do you mean by that?
> On Windows: `C-h k M-<f4>' => "<M-f4> is undefined" (and the key does not appear
> in the `global-map', at least).

Which means that Emacs actively shadows the default binding on w32.

Why should Emacs do that?

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

[Óscar Fuentes]

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

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

If you insist on working at the C level, just handle Alt-F4 as if it
were WM_CLOSE:

swich(event) {
...
case WM_KEYDOWN:
  if( key is Alt-F4 and is unbound )
    do the same as WM_CLOSE

I have no idea how complex is to check from w32term.c if a key is bound.

I can't see why just adding something like

(global-set-key [M-f4] 'delete-frame-maybe-exit-emacs)

is wrong.

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

This is overkill. There are just a few candidates for "events that Emacs
receives but maybe are worth delegating to Windows". One is Alt-F4,
another Ctrl-Space (which activates the application's system menu) Maybe
there is some other. Not worth the trouble, IMO.

> But it still leaves open the question whether it should contain M-f4 or
> A-f4 (or use yet-another event representation),

Is there an [A-f4] key event on Emacs running on Windows? I mean, I've
never seen one. My keyboard says "Alt" but whenever I use that modifier,
Emacs says [M-whatever].

> as well as what happens
> when the user hits C-x M-f4.

That's simple: Alt-F4 is the same as clicking on the window's close
button, so do the same as C-x <click close button>. Hmmm, I see, maybe
that's not possible from Lisp.

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

[PJ Weisberg]

On Fri, Jan 14, 2011 at 9:58 AM, Drew Adams <drew.adams@oracle.com> wrote:

> Slippery slope.  It won't be long before someone will complain that library
> Foobar stomped on `M-f4', the universally recognized standard compulsory model
> key for deleting a window and quitting an app.

Which is exactly what started this thread.  The original question
could be rephrased to "Why does Emacs stomp on `Alt+F4', the
universally recognized standard compulsory model key for closing a
window, by binding it to some function that prints `<M-f4> is
undefined'?"

That's what Lennart meant when he said that Emacs binds Alt+F4 but
doesn't use it.  Other applications would pass it to Windows,
resulting in the window being closed.  Emacs overrides that behavior
by eating the event and printing an error message.

-PJ

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]

> > On Windows: `C-h k M-<f4>' => "<M-f4> is undefined" (and 
> > the key does not appear in the `global-map', at least).
> 
> Which means that Emacs actively shadows the default binding on w32.
> Why should Emacs do that?

Why shouldn't it?  Should Emacs not "actively shadow" `C-c' or `C-d' or ... when
launched from a shell, because those keys mean somthing to the shell?

Since when should Emacs simply reflect outside key bindings?  It can, of course.
And perhaps it should in some particular cases.  But let's drop the argument
that it must as a general rule.  There is nothing wrong with Emacs deciding to
"actively shadow" any key it wants.  (It might not always be successful, but
that is another problem.)

IOW, there is a decision to be made about this specific key.  Not some general
hand-waving argument about Emacs respecting the outside context (or user
expectations or...).

The question is about _this_ key.

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

[Drew Adams]

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

That would be good in any case: give users the option, no matter what the
default behavior is.

We also have `w32-register-hot-key', BTW:
(w32-register-hot-key [M-tab])

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

And it still leaves open the question of the _default_ behavior for this key.
Just which keys should be included by default in user option
`w32-passthrough-events'?

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

[Drew Adams]

> That's what Lennart meant when he said that Emacs binds Alt+F4 but
> doesn't use it.  Other applications would pass it to Windows,
> resulting in the window being closed.  Emacs overrides that behavior
> by eating the event and printing an error message.

Emacs is not just another application.  It binds many keys that have different
behavior outside Emacs.

There is an error message only if you do not bind it - same as for any key.  If
you bind it to `forward-char', then it just invokes `forward-char' - no error
msg.  There are (thankfully) still some keys that do not have default bindings.

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 Sun, Jan 16, 2011 at 10:49 PM, Drew Adams <drew.adams@oracle.com> wrote:
>> > On Windows: `C-h k M-<f4>' => "<M-f4> is undefined" (and
>> > the key does not appear in the `global-map', at least).
>>
>> Which means that Emacs actively shadows the default binding on w32.
>> Why should Emacs do that?
>
> Why shouldn't it?

Because it makes Emacs harder to use (especially for new users).

> Should Emacs not "actively shadow" `C-c' or `C-d' or ... when
> launched from a shell, because those keys mean somthing to the shell?

That is not what I meant by "shadow".

> Since when should Emacs simply reflect outside key bindings?

The invisible Emacs. Everywhere. ;-)

> The question is about _this_ key.

Which does not prevent the discussion to be more general.

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

[Lennart Borgman]

On Sun, Jan 16, 2011 at 10:49 PM, Drew Adams <drew.adams@oracle.com> 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.
>
> 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.

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

[Philipp Haselwarter]

"LB" == Lennart Borgman <lennart.borgman@gmail.com> writes:

LB> On Sun, Jan 16, 2011 at 10:49 PM, Drew Adams <drew.adams@oracle.com> wrote:
>>> > On Windows: `C-h k M-<f4>' => "<M-f4> is undefined" (and > the key
>>> does not appear in the `global-map', at least).
>>> 
>>> Which means that Emacs actively shadows the default binding on w32.
>>> Why should Emacs do that?
>> 
>> Why shouldn't it?

LB> Because it makes Emacs harder to use (especially for new users).
---8<---[snipped 12 lines]---8<---

Learning emacs is _that_ hard already, I'm not sure M-f4 makes a
difference. When you're new to emacs, there is just no way around
actively learning the essential keys anyways.
If you'd want to achieve consistent behaviour with the most-used window
managers, you'd also have to make C-f do search and C-s save.
And that inconsistency is a problem for new users on all platforms.
At my university, I've see people new to linux struggle with emacs, and
believe me, it was not pretty (like, opening a new instance of emacs
instead of using buffers).
Maybe attempting to provide at least as many keybindings doing "what
you'd expect them to do" as possible could help make it easier for new
users. Not sure though. Which makes me think of cua-mode again.

btw, how is M-<tab> handled on Windows?

-- 
Philipp Haselwarter

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).
> 
> 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.  In the example given by PJW the key was
pressed, raising the unbound error (now) or passing to Windows (proposed).
Testing after the key is pressed is different from just testing using `boundp'.

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.

I still prefer Stefan's proposal of `w32-passthrough-events': let users (or
libraries, for that matter) configure the behavior.

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

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

[Drew Adams]

> >>> Why should Emacs do that?
> >> Why shouldn't it?
LB> Because it makes Emacs harder to use (especially for new users).
> 
> Learning emacs is _that_ hard already, I'm not sure M-f4 makes a
> difference. When you're new to emacs, there is just no way around
> actively learning the essential keys anyways.

Not only that, but I would hope that the reason for binding this key in Emacs to
do what it does in Windows would be because that action is common and that this
is the right key for it.

IOW, I would hope that the reason is to make life better for Emacs users in
general, not just for new users.  If the argument boils down to just another
newbie crutch, then that makes it weaker still.

> If you'd want to achieve consistent behaviour with the most-used
> window managers, you'd also have to make C-f do search and C-s save.

Please, don't give him any ideas.  That might well be next on the list...

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

[Drew Adams]

> > Why shouldn't it?
> 
> Because it makes Emacs harder to use (especially for new users).

No harder than learning that C-d in Emacs is not the same as in shell, or that
C-s in Emacs is not the same as in most apps.

Emacs is not shell.  Emacs is not Windows or Gnome.  Emacs is not your average
app.

> > Should Emacs not "actively shadow" `C-c' or `C-d' or ... when
> > launched from a shell, because those keys mean somthing to 
> > the shell?
> 
> That is not what I meant by "shadow".

You didn't say what you meant by it.  How is it different?  You are arguing that
a key that has some action outside Emacs should necessarily have the same action
inside Emacs.  You didn't mention shell, but I did.  What's the diff?

> > Since when should Emacs simply reflect outside key bindings?
> 
> The invisible Emacs. Everywhere. ;-)

Dunno what that means.  Sounds more like "Windows everywhere", to me.

> > The question is about _this_ key.
> 
> Which does not prevent the discussion to be more general.

But your general arguments don't help answer the question about _this_ key.
Same thing for the general argument that because a key is unbound we should give
it a default binding.

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

[Drew Adams]

Minor clarification of what I said:

> 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 

in this way

> , hardcoding it instead of letting anyone code it

this way

> for any purpose.
> But I do recognize that this is not a big use case.

IOW, don't bother to remark that users and libraries could still bind the key.
I know that.  The question was about testing an unbound error after the key is
pressed.

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

[Jason Rumney]

On 17/01/2011 05:49, Drew Adams wrote:
> The best approach, regardless what default behavior is decided on (and I prefer
> it to be unbound), is to let the user decide.

None of the suggestions put forward so far remove the choice of the user 
to bind this key differently. The differences in suggested 
implementation revolve around whether to bind it as a normal Emacs 
keybinding, or stay closer to the way the key is normally handled in 
other applications (and in Emacs on X desktops where the key is handled 
by the Window Manager).

I honestly can't see what it is you are arguing against.

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

[Lennart Borgman]

On Mon, Jan 17, 2011 at 2:45 AM, Drew Adams <drew.adams@oracle.com> wrote:
>> > Why shouldn't it?
>>
>> Because it makes Emacs harder to use (especially for new users).
>
> No harder than learning that C-d in Emacs is not the same as in shell, or that
> C-s in Emacs is not the same as in most apps.

I have said a lot of times here on Emacs Devel that more details that
makes it different matter because it makes it more complex to learn
Emacs. And complexity is probably in many cases rather an exponential
function of differing details than a linear function of it.

Is there something unclear about that argument? (Yes, I can explain it
more in details, but I have not felt the need here.)


>> > Should Emacs not "actively shadow" `C-c' or `C-d' or ... when
>> > launched from a shell, because those keys mean somthing to
>> > the shell?
>>
>> That is not what I meant by "shadow".
>
> You didn't say what you meant by it.  How is it different?  You are arguing that
> a key that has some action outside Emacs should necessarily have the same action
> inside Emacs.  You didn't mention shell, but I did.  What's the diff?

It is a similar situation but Emacs position is the master in this
case while the operating system is the master in the case we are
discussing. We try to avoid complexities when interacting with
subprocesses by presenting them in similar ways to Emacs users. I
think that is good. What I am saying is that I believe it is good to
present Emacs in a similar way to users as other apps - as long as it
does not hamper Emacs.

Actually I believe you think that is good too since you have not
really said anything against it.


>> > Since when should Emacs simply reflect outside key bindings?
>>
>> The invisible Emacs. Everywhere. ;-)
>
> Dunno what that means.  Sounds more like "Windows everywhere", to me.

Yes. I am just mirroring your argument which I found absurd. ;-)


>> > The question is about _this_ key.
>>
>> Which does not prevent the discussion to be more general.
>
> But your general arguments don't help answer the question about _this_ key.

Why not? I am surprised by that argument.

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?

[Stephen J. Turnbull]

Lennart Borgman writes:
 > On Mon, Jan 17, 2011 at 2:45 AM, Drew Adams <drew.adams@oracle.com> wrote:

 > > You didn't say what you meant by it.  How is it different?  You
 > > are arguing that a key that has some action outside Emacs should
 > > necessarily have the same action inside Emacs.

That may or may not be what he's arguing, but it seems to me the
question here is "if a key has a familiar 'generic' binding that is
applicable to and useful in Emacs, *and* Emacs itself doesn't bind
that key, should Emacs 'use' the generic binding by default?"  And the
answer "yes" follows from the principle of least astonishment.

Since Windows has a way of providing a fallback binding for events, it
seems to me that unless Emacs has a reason *not* to use that fallback,
such as "Emacs has bound a function to that event" or "in Emacs that
behavior is stupid/useless/harmful" or "the user says he doesn't like
it", it should be allowed to fall through to the fallback when the
Emacs binding is void.

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

[Lennart Borgman]

On Mon, Jan 17, 2011 at 9:47 AM, Stephen J. Turnbull <stephen@xemacs.org> wrote:
>
> That may or may not be what he's arguing, but it seems to me the
> question here is "if a key has a familiar 'generic' binding that is
> applicable to and useful in Emacs, *and* Emacs itself doesn't bind
> that key, should Emacs 'use' the generic binding by default?"  And the
> answer "yes" follows from the principle of least astonishment.

Thanks. Yes.

> Since Windows has a way of providing a fallback binding for events, it
> seems to me that unless Emacs has a reason *not* to use that fallback,
> such as "Emacs has bound a function to that event" or "in Emacs that
> behavior is stupid/useless/harmful" or "the user says he doesn't like
> it", it should be allowed to fall through to the fallback when the
> Emacs binding is void.

What I really hoped to discuss where the technical difficulties. Emacs
does not currently have a way to let key binding fall back to the OS
binding. I am not sure it is trivial and I have forgotten the details.

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

[Drew Adams]

> > The best approach, regardless what default behavior is 
> > decided on (and I prefer it to be unbound), is to let
> > the user decide.
> 
> None of the suggestions put forward so far remove the choice 
> of the user to bind this key differently....

No one said they did.

> I honestly can't see what it is you are arguing against.

And yet I was clear:

> I still prefer Stefan's proposal of `w32-passthrough-events':
> let users (or libraries, for that matter) configure the behavior.
>
> Better still would be to (a) let users bind `M-f4' in Emacs,
> but if unbound (b) look it up in `w32-passthrough-events' and
> if there pass it to Windows, or if not there (c) raise an
> unbound error.

Let users (and libraries) not only bind it but also specify what to do if
unbound: pass through to Windows or raise an error.

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

[Drew Adams]

> unless ... "the user says he doesn't like it", it should be
> allowed to fall through to the fallback when the Emacs
> binding is void.

I argued that the user (and libraries) should be able to not only bind the key
(which no one has disagreed with) but also specify what to do if it is unbound:
raise an error or pass it through to Windows.

That's feasible with Stefan's proposal (assuming implementation details can be
addressed, which need to be addressed anyway for the pass-through).  And it
gives users and libraries the choice, at runtime, that you are trying to make
here, at design time.  Not only least astonishment but most control.

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?

[Drew Adams]

> >> > Should Emacs not "actively shadow" `C-c' or `C-d' or ... when
> >> > launched from a shell, because those keys mean somthing to
> >> > the shell?
>
> That is not what I meant by "shadow".
> It is a similar situation but Emacs position is the master in this
> case while the operating system is the master in the case we are
> discussing.

Define "master".  You can certainly launch Emacs in background from a shell,
then kill it from the shell.  So much for Emacs being in control of the shell.
Why shouldn't Emacs pass C-c or C-d through to the shell, by your logic?

(Alt-F4 isn't OS, it's window mgr, though admittedly for Windows the two are
conflated.)

What is the hierachy you see and how does it relate to key bindings?  There are
several possible environments outside Emacs, all of which can have their own key
bindings.

* shell where you invoke Emacs (C-c,...)
* Window manager (Alt-F3,...)
* OS
* other outside apps with their "standard" keys (C-s, ...)
* ... (?)

Which ones should take precedence over Emacs when a key is unbound in Emacs
(pass-through)?  Which ones should take precedence even if a key _is_ bound in
Emacs?

I would say give Emacs users and libraries the choice whenever possible,
including the choice to do nothing or to raise an unbound error for a key that
some outside environment might normally handle.

If they choose to pass some things through to the outside or to mimic particular
outside (e.g. "standard") actions, so be it.

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.

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

[Óscar Fuentes]

"Drew Adams" <drew.adams@oracle.com> writes:

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

(global-set-key [M-f4]
  (lambda () (interactive) (message "Emacs ate your M-f4")))

See: with #1 and #3 the user can prevent sending Alt-F4 back to
Windows. No need for #2.

BTW: how is useful for the user to show an unbound error instead of
doing what is advertised on a menu and a platform's UI standard
procedure?

[snip]

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

[Lennart Borgman]

On Mon, Jan 17, 2011 at 8:02 PM, Drew Adams <drew.adams@oracle.com> wrote:
>>
>> 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.

This is a misunderstanding. We have not even been discussing this. No
one has said that users and libraries should not be able to bind M-f4.


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

Please do not try to win by dismissing important details, it is
useless and wastes our time. You are mixing to very different things
here.

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.
> 
> (global-set-key [M-f4] (lambda () (interactive)...))
> See: with #1 and #3 the user can prevent sending Alt-F4 back to
> Windows. No need for #2.

That's nothing new.  See #1 above - users can bind M-f4.  Everyone has
recognized that from the beginning.

> how is useful for the user to show an unbound error instead of
> doing what is advertised on a menu and a platform's UI standard
> procedure?

Why not?  And why shouldn't a library be able to do that?  Why arbitrarily take
away that control?  An error represents information, and it can be used for
program control.

The technical difficulties in this thread apparently involve how to pass-through
to Windows.  In any case, (AFAICT) they have nothing to do with not allowing
users a choice.  Why preclude that choice if there is no technical reason to?  

Why even argue against this?  I really don't understand.  No one is insisting
that Alt-f4 can never be sent to Windows.  And you agree that users have and
should continue to have the choice of binding the key in Emacs.  Why not also
give them the choice over what to do if the key is unbound?  Where's the beef?

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 go! Why is <M-f4> unbound?

[jasonr]

Quoting Drew Adams <drew.adams@oracle.com>:

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

Because Emacs is already too complicated for users to configure. It seems you
are advocating making it more complicated purely for the vague notion that some
hypothetical library might want to do something with keys that are unbound
within Emacs, and hardcoding the behaviour of #3 would interfere with that for
this one key (which is bound outside of Emacs).

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