20.7.10 Miscellaneous System Events

This kind of event indicates that the user gave the window manager
a command to delete a particular window, which happens to be an Emacs frame.

The standard definition of the delete-frame event is to delete frame.

(iconify-frame (frame))

This kind of event indicates that the user iconified frame using
the window manager. Its standard definition is ignore; since the
frame has already been iconified, Emacs has no work to do. The purpose
of this event type is so that you can keep track of such events if you
want to.

(make-frame-visible (frame))

This kind of event indicates that the user deiconified frame using
the window manager. Its standard definition is ignore; since the
frame has already been made visible, Emacs has no work to do.

(wheel-up position)

(wheel-down position)

These kinds of event are generated by moving a mouse wheel. The
position element is a mouse position list (see Click Events), specifying the position of the mouse cursor when the event
occurred.

This kind of event is generated only on some kinds of systems. On some
systems, mouse-4 and mouse-5 are used instead. For
portable code, use the variables mouse-wheel-up-event and
mouse-wheel-down-event defined in mwheel.el to determine
what event types to expect for the mouse wheel.

(drag-n-drop positionfiles)

This kind of event is generated when a group of files is
selected in an application outside of Emacs, and then dragged and
dropped onto an Emacs frame.

The element position is a list describing the position of the
event, in the same format as used in a mouse-click event (see Click Events), and files is the list of file names that were dragged
and dropped. The usual way to handle this event is by visiting these
files.

This kind of event is generated, at present, only on some kinds of
systems.

help-echo

This kind of event is generated when a mouse pointer moves onto a
portion of buffer text which has a help-echo text property.
The generated event has this form:

(help-echo framehelpwindowobjectpos)

The precise meaning of the event parameters and the way these
parameters are used to display the help-echo text are described in
Text help-echo.

sigusr1

sigusr2

These events are generated when the Emacs process receives
the signals SIGUSR1 and SIGUSR2. They contain no
additional data because signals do not carry additional information.
They can be useful for debugging (see Error Debugging).

To catch a user signal, bind the corresponding event to an interactive
command in the special-event-map (see Active Keymaps).
The command is called with no arguments, and the specific signal event is
available in last-input-event. For example:

To test the signal handler, you can make Emacs send a signal to itself:

(signal-process (emacs-pid) 'sigusr1)

language-change

This kind of event is generated on MS-Windows when the input language
has changed. This typically means that the keyboard keys will send to
Emacs characters from a different language. The generated event has
this form:

(language-change framecodepagelanguage-id)

Here frame is the frame which was current when the input
language changed; codepage is the new codepage number; and
language-id is the numerical ID of the new input language. The
coding-system (see Coding Systems) that corresponds to
codepage is cpcodepage or
windows-codepage. To convert language-id to a
string (e.g., to use it for various language-dependent features, such
as set-language-environment), use the
w32-get-locale-info function, like this:

;; Get the abbreviated language name, such as "ENU" for English
(w32-get-locale-info language-id)
;; Get the full English name of the language,
;; such as "English (United States)"
(w32-get-locale-info language-id 4097)
;; Get the full localized name of the language
(w32-get-locale-info language-id t)

If one of these events arrives in the middle of a key sequence—that
is, after a prefix key—then Emacs reorders the events so that this
event comes either before or after the multi-event key sequence, not
within it.