* RE: Bikeshedding "user choice"
@ 2011-01-19 21:51 grischka
2011-01-19 23:27 ` Drew Adams
0 siblings, 1 reply; 9+ messages in thread
From: grischka @ 2011-01-19 21:51 UTC (permalink / raw)
To: drew.adams; +Cc: emacs-devel
> 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
^ permalink raw reply [flat|nested] 9+ messages in thread
* RE: Bikeshedding "user choice" 2011-01-19 21:51 Bikeshedding "user choice" grischka @ 2011-01-19 23:27 ` Drew Adams 2011-01-20 18:18 ` grischka 0 siblings, 1 reply; 9+ messages in thread From: Drew Adams @ 2011-01-19 23:27 UTC (permalink / raw) To: 'grischka'; +Cc: emacs-devel > > 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... ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Bikeshedding "user choice" 2011-01-19 23:27 ` Drew Adams @ 2011-01-20 18:18 ` grischka 0 siblings, 0 replies; 9+ messages in thread From: grischka @ 2011-01-20 18:18 UTC (permalink / raw) To: Drew Adams; +Cc: emacs-devel 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... ^ permalink raw reply [flat|nested] 9+ messages in thread
* Bikeshedding go! Why is <M-f4> unbound? @ 2011-01-05 14:48 Deniz Dogan 2011-01-05 15:29 ` Óscar Fuentes 0 siblings, 1 reply; 9+ messages in thread From: Deniz Dogan @ 2011-01-05 14:48 UTC (permalink / raw) To: Emacs-Devel devel 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Bikeshedding go! Why is <M-f4> unbound? 2011-01-05 14:48 Bikeshedding go! Why is <M-f4> unbound? Deniz Dogan @ 2011-01-05 15:29 ` Óscar Fuentes 2011-01-05 17:11 ` Deniz Dogan 0 siblings, 1 reply; 9+ messages in thread From: Óscar Fuentes @ 2011-01-05 15:29 UTC (permalink / raw) To: emacs-devel 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Bikeshedding go! Why is <M-f4> unbound? 2011-01-05 15:29 ` Óscar Fuentes @ 2011-01-05 17:11 ` Deniz Dogan 2011-01-05 17:30 ` Eli Zaretskii 0 siblings, 1 reply; 9+ messages in thread From: Deniz Dogan @ 2011-01-05 17:11 UTC (permalink / raw) To: Óscar Fuentes; +Cc: emacs-devel 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Bikeshedding go! Why is <M-f4> unbound? 2011-01-05 17:11 ` Deniz Dogan @ 2011-01-05 17:30 ` Eli Zaretskii 2011-01-05 17:36 ` Deniz Dogan 0 siblings, 1 reply; 9+ messages in thread From: Eli Zaretskii @ 2011-01-05 17:30 UTC (permalink / raw) To: Deniz Dogan; +Cc: ofv, emacs-devel > 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Bikeshedding go! Why is <M-f4> unbound? 2011-01-05 17:30 ` Eli Zaretskii @ 2011-01-05 17:36 ` Deniz Dogan 2011-01-05 18:15 ` Óscar Fuentes 0 siblings, 1 reply; 9+ messages in thread From: Deniz Dogan @ 2011-01-05 17:36 UTC (permalink / raw) To: Eli Zaretskii; +Cc: ofv, emacs-devel 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Bikeshedding go! Why is <M-f4> unbound? 2011-01-05 17:36 ` Deniz Dogan @ 2011-01-05 18:15 ` Óscar Fuentes 2011-01-09 22:00 ` Lennart Borgman 0 siblings, 1 reply; 9+ messages in thread From: Óscar Fuentes @ 2011-01-05 18:15 UTC (permalink / raw) To: emacs-devel 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Bikeshedding go! Why is <M-f4> unbound? 2011-01-05 18:15 ` Óscar Fuentes @ 2011-01-09 22:00 ` Lennart Borgman 2011-01-10 1:01 ` Drew Adams 0 siblings, 1 reply; 9+ messages in thread From: Lennart Borgman @ 2011-01-09 22:00 UTC (permalink / raw) To: Óscar Fuentes; +Cc: emacs-devel 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). ^ permalink raw reply [flat|nested] 9+ messages in thread
* RE: Bikeshedding go! Why is <M-f4> unbound? 2011-01-09 22:00 ` Lennart Borgman @ 2011-01-10 1:01 ` Drew Adams 2011-01-12 13:53 ` Stuart Hacking 0 siblings, 1 reply; 9+ messages in thread From: Drew Adams @ 2011-01-10 1:01 UTC (permalink / raw) To: 'Lennart Borgman', 'Óscar Fuentes'; +Cc: emacs-devel > 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.) ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Bikeshedding go! Why is <M-f4> unbound? 2011-01-10 1:01 ` Drew Adams @ 2011-01-12 13:53 ` Stuart Hacking 2011-01-12 15:01 ` Drew Adams 0 siblings, 1 reply; 9+ messages in thread From: Stuart Hacking @ 2011-01-12 13:53 UTC (permalink / raw) To: Drew Adams; +Cc: Óscar Fuentes, Lennart Borgman, emacs-devel 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? ^ permalink raw reply [flat|nested] 9+ messages in thread
* RE: Bikeshedding go! Why is <M-f4> unbound? 2011-01-12 13:53 ` Stuart Hacking @ 2011-01-12 15:01 ` Drew Adams 2011-01-12 15:54 ` Deniz Dogan 0 siblings, 1 reply; 9+ messages in thread From: Drew Adams @ 2011-01-12 15:01 UTC (permalink / raw) To: 'Stuart Hacking' Cc: 'Óscar Fuentes', 'Lennart Borgman', emacs-devel > > 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Bikeshedding go! Why is <M-f4> unbound? 2011-01-12 15:01 ` Drew Adams @ 2011-01-12 15:54 ` Deniz Dogan 2011-01-12 20:32 ` Stefan Monnier 0 siblings, 1 reply; 9+ messages in thread From: Deniz Dogan @ 2011-01-12 15:54 UTC (permalink / raw) To: Drew Adams Cc: Stuart Hacking, Óscar Fuentes, Lennart Borgman, emacs-devel 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Bikeshedding go! Why is <M-f4> unbound? 2011-01-12 15:54 ` Deniz Dogan @ 2011-01-12 20:32 ` Stefan Monnier 2011-01-12 20:42 ` Deniz Dogan 0 siblings, 1 reply; 9+ messages in thread From: Stefan Monnier @ 2011-01-12 20:32 UTC (permalink / raw) To: Deniz Dogan Cc: Stuart Hacking, Óscar Fuentes, Lennart Borgman, Drew Adams, emacs-devel > 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Bikeshedding go! Why is <M-f4> unbound? 2011-01-12 20:32 ` Stefan Monnier @ 2011-01-12 20:42 ` Deniz Dogan 2011-01-13 2:42 ` Stefan Monnier 0 siblings, 1 reply; 9+ messages in thread From: Deniz Dogan @ 2011-01-12 20:42 UTC (permalink / raw) To: Stefan Monnier Cc: Stuart Hacking, Óscar Fuentes, Lennart Borgman, Drew Adams, emacs-devel 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Bikeshedding go! Why is <M-f4> unbound? 2011-01-12 20:42 ` Deniz Dogan @ 2011-01-13 2:42 ` Stefan Monnier 2011-01-13 3:59 ` Óscar Fuentes 0 siblings, 1 reply; 9+ messages in thread From: Stefan Monnier @ 2011-01-13 2:42 UTC (permalink / raw) To: Deniz Dogan Cc: Stuart Hacking, Óscar Fuentes, Lennart Borgman, Drew Adams, emacs-devel > 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Bikeshedding go! Why is <M-f4> unbound? 2011-01-13 2:42 ` Stefan Monnier @ 2011-01-13 3:59 ` Óscar Fuentes 2011-01-14 10:49 ` PJ Weisberg 0 siblings, 1 reply; 9+ messages in thread From: Óscar Fuentes @ 2011-01-13 3:59 UTC (permalink / raw) To: Stefan Monnier Cc: Stuart Hacking, emacs-devel, Lennart Borgman, Drew Adams, Deniz Dogan 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". ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Bikeshedding go! Why is <M-f4> unbound? 2011-01-13 3:59 ` Óscar Fuentes @ 2011-01-14 10:49 ` PJ Weisberg 2011-01-14 15:48 ` Stefan Monnier 0 siblings, 1 reply; 9+ messages in thread From: PJ Weisberg @ 2011-01-14 10:49 UTC (permalink / raw) To: Emacs-Devel devel 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Bikeshedding go! Why is <M-f4> unbound? 2011-01-14 10:49 ` PJ Weisberg @ 2011-01-14 15:48 ` Stefan Monnier 2011-01-15 11:41 ` Lennart Borgman 0 siblings, 1 reply; 9+ messages in thread From: Stefan Monnier @ 2011-01-14 15:48 UTC (permalink / raw) To: PJ Weisberg; +Cc: Emacs-Devel devel > 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Bikeshedding go! Why is <M-f4> unbound? 2011-01-14 15:48 ` Stefan Monnier @ 2011-01-15 11:41 ` Lennart Borgman 2011-01-16 21:49 ` Drew Adams 0 siblings, 1 reply; 9+ messages in thread From: Lennart Borgman @ 2011-01-15 11:41 UTC (permalink / raw) To: Stefan Monnier; +Cc: PJ Weisberg, Emacs-Devel devel 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.) ^ permalink raw reply [flat|nested] 9+ messages in thread
* RE: Bikeshedding go! Why is <M-f4> unbound? 2011-01-15 11:41 ` Lennart Borgman @ 2011-01-16 21:49 ` Drew Adams [not found] ` <227F94B0AC1649C1A41082A24!9921783@us.oracle!! ! .com> ` (3 more replies) 0 siblings, 4 replies; 9+ messages in thread From: Drew Adams @ 2011-01-16 21:49 UTC (permalink / raw) To: 'Lennart Borgman', 'Stefan Monnier' Cc: 'PJ Weisberg', 'Emacs-Devel devel' > >> 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'). ^ permalink raw reply [flat|nested] 9+ messages in thread
[parent not found: <227F94B0AC1649C1A41082A24!9921783@us.oracle!! ! .com>]
[parent not found: <227F94B0AC1649C1A41082A24! 9921783@us.oracle! .com>]
[parent not found: <227F94B0AC1649C1A41082A24!9921783@us.oracle!! .com>]
[parent not found: <227F94B0AC1649C1A41082A24! 9921783@us.oracle.com >]
* Re: Bikeshedding go! Why is <M-f4> unbound? @ 2011-01-17 8:32 ` Lennart Borgman 2011-01-17 18:22 ` Drew Adams 0 siblings, 1 reply; 9+ messages in thread From: Lennart Borgman @ 2011-01-17 8:32 UTC (permalink / raw) To: Drew Adams; +Cc: Stefan Monnier, PJ Weisberg, Emacs-Devel devel 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
* RE: Bikeshedding go! Why is <M-f4> unbound? 2011-01-17 8:32 ` Lennart Borgman @ 2011-01-17 18:22 ` Drew Adams 2011-01-17 18:36 ` Lennart Borgman 0 siblings, 1 reply; 9+ messages in thread From: Drew Adams @ 2011-01-17 18:22 UTC (permalink / raw) To: 'Lennart Borgman' Cc: 'Stefan Monnier', 'PJ Weisberg', 'Emacs-Devel devel' > > 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Bikeshedding go! Why is <M-f4> unbound? 2011-01-17 18:22 ` Drew Adams @ 2011-01-17 18:36 ` Lennart Borgman 2011-01-17 19:02 ` Drew Adams 0 siblings, 1 reply; 9+ messages in thread From: Lennart Borgman @ 2011-01-17 18:36 UTC (permalink / raw) To: Drew Adams; +Cc: Stefan Monnier, PJ Weisberg, Emacs-Devel devel 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
* RE: Bikeshedding go! Why is <M-f4> unbound? 2011-01-17 18:36 ` Lennart Borgman @ 2011-01-17 19:02 ` Drew Adams 2011-01-18 3:20 ` Bikeshedding "user choice" Stephen J. Turnbull 0 siblings, 1 reply; 9+ messages in thread From: Drew Adams @ 2011-01-17 19:02 UTC (permalink / raw) To: 'Lennart Borgman' Cc: 'Stefan Monnier', 'PJ Weisberg', 'Emacs-Devel devel' > > 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Bikeshedding "user choice" 2011-01-17 19:02 ` Drew Adams @ 2011-01-18 3:20 ` Stephen J. Turnbull 2011-01-18 5:29 ` Drew Adams 0 siblings, 1 reply; 9+ messages in thread From: Stephen J. Turnbull @ 2011-01-18 3:20 UTC (permalink / raw) To: Drew Adams; +Cc: 'Emacs-Devel devel' 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!) ^ permalink raw reply [flat|nested] 9+ messages in thread
* RE: Bikeshedding "user choice" 2011-01-18 3:20 ` Bikeshedding "user choice" Stephen J. Turnbull @ 2011-01-18 5:29 ` Drew Adams 2011-01-18 6:11 ` Stephen J. Turnbull 0 siblings, 1 reply; 9+ messages in thread From: Drew Adams @ 2011-01-18 5:29 UTC (permalink / raw) To: 'Stephen J. Turnbull'; +Cc: 'Emacs-Devel devel' > 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
* RE: Bikeshedding "user choice" 2011-01-18 5:29 ` Drew Adams @ 2011-01-18 6:11 ` Stephen J. Turnbull 2011-01-18 17:45 ` Drew Adams 0 siblings, 1 reply; 9+ messages in thread From: Stephen J. Turnbull @ 2011-01-18 6:11 UTC (permalink / raw) To: Drew Adams; +Cc: 'Emacs-Devel devel' 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). ^ permalink raw reply [flat|nested] 9+ messages in thread
* RE: Bikeshedding "user choice" 2011-01-18 6:11 ` Stephen J. Turnbull @ 2011-01-18 17:45 ` Drew Adams 2011-01-19 4:59 ` Stephen J. Turnbull 0 siblings, 1 reply; 9+ messages in thread From: Drew Adams @ 2011-01-18 17:45 UTC (permalink / raw) To: 'Stephen J. Turnbull'; +Cc: 'Emacs-Devel devel' > > > 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
* RE: Bikeshedding "user choice" 2011-01-18 17:45 ` Drew Adams @ 2011-01-19 4:59 ` Stephen J. Turnbull 2011-01-19 19:34 ` Drew Adams 0 siblings, 1 reply; 9+ messages in thread From: Stephen J. Turnbull @ 2011-01-19 4:59 UTC (permalink / raw) To: Drew Adams; +Cc: 'Emacs-Devel devel' 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
* RE: Bikeshedding "user choice" 2011-01-19 4:59 ` Stephen J. Turnbull @ 2011-01-19 19:34 ` Drew Adams 0 siblings, 0 replies; 9+ messages in thread From: Drew Adams @ 2011-01-19 19:34 UTC (permalink / raw) To: 'Stephen J. Turnbull'; +Cc: 'Emacs-Devel devel' > > 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2011-01-20 18:18 UTC | newest] Thread overview: 9+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2011-01-19 21:51 Bikeshedding "user choice" grischka 2011-01-19 23:27 ` Drew Adams 2011-01-20 18:18 ` grischka -- strict thread matches above, loose matches on Subject: below -- 2011-01-05 14:48 Bikeshedding go! Why is <M-f4> unbound? Deniz Dogan 2011-01-05 15:29 ` Óscar Fuentes 2011-01-05 17:11 ` Deniz Dogan 2011-01-05 17:30 ` Eli Zaretskii 2011-01-05 17:36 ` Deniz Dogan 2011-01-05 18:15 ` Óscar Fuentes 2011-01-09 22:00 ` Lennart Borgman 2011-01-10 1:01 ` Drew Adams 2011-01-12 13:53 ` Stuart Hacking 2011-01-12 15:01 ` Drew Adams 2011-01-12 15:54 ` Deniz Dogan 2011-01-12 20:32 ` Stefan Monnier 2011-01-12 20:42 ` Deniz Dogan 2011-01-13 2:42 ` Stefan Monnier 2011-01-13 3:59 ` Óscar Fuentes 2011-01-14 10:49 ` PJ Weisberg 2011-01-14 15:48 ` Stefan Monnier 2011-01-15 11:41 ` Lennart Borgman 2011-01-16 21:49 ` Drew Adams [not found] ` <227F94B0AC1649C1A41082A24!9921783@us.oracle!! ! .com> [not found] ` <227F94B0AC1649C1A41082A24! 9921783@us.oracle! .com> [not found] ` <227F94B0AC1649C1A41082A24!9921783@us.oracle!! .com> [not found] ` <227F94B0AC1649C1A41082A24! 9921783@us.oracle.com > 2011-01-17 8:32 ` Lennart Borgman 2011-01-17 18:22 ` Drew Adams 2011-01-17 18:36 ` Lennart Borgman 2011-01-17 19:02 ` Drew Adams 2011-01-18 3:20 ` Bikeshedding "user choice" Stephen J. Turnbull 2011-01-18 5:29 ` Drew Adams 2011-01-18 6:11 ` Stephen J. Turnbull 2011-01-18 17:45 ` Drew Adams 2011-01-19 4:59 ` Stephen J. Turnbull 2011-01-19 19:34 ` Drew Adams
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.