[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Óscar Fuentes
Subject: Re: Bikeshedding go! Why is <M-f4> unbound?
Date: Thu, 13 Jan 2011 04:59:26 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux)

Stefan Monnier <address@hidden> writes:


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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]