Re: Bikeshedding go! Why is <M-f4> unbound?
grischka
>>>> 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?
There is this in w32fns.c:
case WM_KEYDOWN:
case WM_SYSKEYDOWN:
...
which basically should be
case WM_SYSKEYDOWN:
if (!is_key_bound_in_emacs(key_param))
goto dflt;
case WM_KEYDOWN:
...
Provided that emacs has a way to check whether a key is bound,
on that level. And if so that the method can be called from
another thread ;)
--- grischka
Jason Rumney
>
>> 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.
PJ Weisberg
> Stefan Monnier <mon...@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.
>
> 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....@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
Lennart Borgman
>> > 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?
Jason Rumney
> 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.
Óscar Fuentes
>> 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.
Lennart Borgman
<mon...@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.
>
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.)
Lennart Borgman
>
> 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.
grischka
> 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.
It is nontrivial to say the least.
Unlike XEmacs, GNU Emacs is still a console application at its heart.
It wants to "read" events in a loop from an input stream until it
finds them complete as a "key-sequence". No function seems to exist
that could deal with events that are already read.
So I guess at first you'd need to convert keyboard.c:read_key_sequence()
from procedural logic into a state machine such that it does not call
'read_key()' on its own but instead can be fed with keys one by one.
Once you have that however you can as well run the Windows backend in
the same thread and many things become much simpler ;)
--- grischka
Lennart Borgman
> grischka <gri...@gmx.de> writes:
>
>>> 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.
>>
>> It is nontrivial to say the least.
>>
>> Unlike XEmacs, GNU Emacs is still a console application at its heart.
>> It wants to "read" events in a loop from an input stream until it
>> finds them complete as a "key-sequence". No function seems to exist
>> that could deal with events that are already read.
>
> receives Alt-F4 in a single event. What is needed is to determine from
> that event loop if there is a binding for Alt-F4 (created with *-set-key
> etc). Once we know that there is no such binding, it is trivial to send
> back the Alt-F4 event back to Windows.
That is correct IF you can send it back directly, i.e. just forward it
to w32 default message loop. If you can't do it directly (because for
example that it is hard to determine directly if there is a key
binding) then I do not think it is that simple. (See my other reply
for why.)
Drew Adams
> > 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.
Lennart Borgman
>> > 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.
Drew Adams
> 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.
Drew Adams
> > 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...@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.
Drew Adams
> > (whatever is done or not done) both users and libraries
> > should feel free to bind M-f4 in Emacs.
>
> one has said that users and libraries should not be able to bind M-f4.
I don't know what the misunderstanding is. You seem to be in violent agreement.
We are both saying that it is agreed by all that users and libraries should be
able to bind M-f4 in Emacs.
If you agree, then in your words, "how both users and libraries could decide on
this"? The answer to that applies also to how both can decide about the
behavior of unbound M-f4 (whether to raise an error or pass to Windows).
> >> >> 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.
No idea what you're talking about. What details? What two things?
You stated both (a) "Yes, I actually do prefer #3 hard-coded" and (b) "No one
has suggested that Alt+F4 should be hardcoded to be sent to w32." (The latter
was in the context of handling an _unbound_ key.) You are someone, not no one.
I think (but am not sure at this point) that your position is (a): you want to
hard-code the behavior that unbound Alt+F4/M-f4 should always be sent to w32.
Lennart Borgman
>> > 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.
Lennart Borgman
>> > 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.
>
> I don't know what the misunderstanding is.
That the ability to bind M-f4 is something we discussed here. No one
has argued that it should not be possible to bind M-f4, just as today.
>> >> >> 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.
>
> No idea what you're talking about. What details? What two things?
It looks to me you are mixing the question whether M-f4 should be
possible to bind with what should happen when it is unbound.
I do not understand why. Maybe it is my fault, but could we just
please stop discussing such things. The only relevant thing here is
what should happen when a key like M-f4 is unbound.
> You stated both (a) "Yes, I actually do prefer #3 hard-coded" and (b) "No one
> has suggested that Alt+F4 should be hardcoded to be sent to w32." (The latter
> was in the context of handling an _unbound_ key.) You are someone, not no one.
>
> I think (but am not sure at this point) that your position is (a): you want to
> hard-code the behavior that unbound Alt+F4/M-f4 should always be sent to w32.
Yes, I prefer (a) over the current situation, but (as I said) I have
nothing against making it a user choice. (It can't be a library choice
AFAICS since no library is involved for an unbound key, but of course
a library coiuld provide ways for the user to make this choice.)
So, thanks, we are back at the part of the question that I believe
really interests you. I have asked you what advantage you see giving a
"not bound" error message when a key is unbound.
I can't really see any. If a user want to see if a key is free they
should use for example "C-h c" which I of course think should give
relevant information. (Yes, I can see some difficulties with that
since Emacs must be taught this info.)