A few other event types represent occurrences within the system.
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.
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
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.
This kind of event indicates that the user’s finger moved off the mouse wheel or the touchpad. The position element is a mouse position list (see Click Events), specifying the position of the mouse cursor when the finger moved off the mouse wheel.
(wheel-up position clicks lines pixel-delta)
(wheel-down position clicks lines pixel-delta)
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.
clicks, if present, is the number of times that the wheel was
moved in quick succession. See Repeat Events. lines, if
present and not
nil, is the number of screen lines that should
be scrolled. pixel-delta, if present, is a cons cell of the
(x . y), where x and y are the
numbers of pixels by which to scroll in each axis, a.k.a.
You can use these x and y pixelwise deltas to determine how much the mouse wheel has actually moved at pixel resolution. For example, the pixelwise deltas could be used to scroll the display at pixel resolution, exactly according to the user’s turning the mouse wheel.
This kind of event is generated only on some kinds of systems. On
mouse-5 are used instead. For
portable code, use the variables
mouse-wheel-down-alternate-event defined in
mwheel.el to determine what event types to expect for the mouse
Similarly, some mice can generate
mouse-wheel-right-event and can be used to scroll if
mouse-wheel-tilt-scroll is non-
nil. However, some mice
also generate other events at the same time as they’re generating
these scroll events which may get in the way. The way to fix this is
generally to unbind these events (for instance,
mouse-7, but this is very hardware and operating system
(pinch position dx dy scale angle)
This kind of event is generated by the user performing a “pinch” gesture by placing two fingers on a touchpad and moving them towards or away from each other. position is a mouse position list (see Click Events) that provides the position of the mouse pointer when the event occurred, dx is the change in the horizontal distance between the fingers since the last event in the same sequence, dy is the vertical movement of the fingers since the last event in the same sequence, scale is the ratio of the current distance between the fingers to that distance at the start of the sequence, and angle is the angular difference in degrees between the direction of the line connecting the fingers in this event and the direction of that line in the last event of the same sequence.
As pinch events are only sent at the beginning or during a pinch sequence, they do not report gestures where the user moves two fingers on a touchpad in a rotating fashion without pinching the fingers.
All arguments after position are floating point numbers.
This event is usually sent as part of a sequence, which begins with
the user placing two fingers on the touchpad, and ends with the user
removing those fingers. dx, dy, and angle will be
0.0 in the first event of a sequence; subsequent events will
report non-zero values for these members of the event structure.
dx and dy are reported in imaginary relative units, in
1.0 is the width and height of the touchpad
respectively. They are usually interpreted as being relative to the
size of the object beneath the gesture: image, window, etc.
This event is sent when a system input method tells Emacs to display some text to indicate to the user what will be inserted. The contents of arg are dependent on the window system being used.
On X, arg is a string describing some text to place behind the
cursor. It can be
nil, which means to remove any text
On PGTK frames (see Frames), arg is a list of strings with information about their color and underline attributes. It has the following form:
((string1 (ul . underline-color) (bg . background-color) (fg . foreground-color)) (string2 (ul . underline-color) (bg . background-color) (fg . foreground-color)) … )
Color information can be omitted, leaving just the text of the
strings. underline-color can be
t, meaning underlined
text with default underline color, or it can be a string, the name of
the color to draw the underline.
This is a special event (see Special Events), which normally should not be bound by the user to any command. Emacs will typically display the text contained in the event in an overlay behind point when it is received.
(drag-n-drop position files)
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.
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 frame help window object pos)
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.
These events are generated when the Emacs process receives
SIGUSR2. They contain no
additional data because signals do not carry additional information.
They can be useful for debugging (see Entering the Debugger on an Error).
To catch a user signal, bind the corresponding event to an interactive
command in the
special-event-map (see Controlling the Active Keymaps).
The command is called with no arguments, and the specific signal event is
last-input-event (see Miscellaneous Event Input Features. For
(defun sigusr-handler () (interactive) (message "Caught signal %S" last-input-event)) (keymap-set special-event-map "<sigusr1>" 'sigusr-handler)
To test the signal handler, you can make Emacs send a signal to itself:
(signal-process (emacs-pid) 'sigusr1)
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 frame codepage language-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
windows-codepage. To convert language-id to a
string (e.g., to use it for various language-dependent features, such
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)
This event is generated on MS-Windows when the operating system
informs Emacs that the user terminated the interactive session, or
that the system is shutting down. The standard definition of this
event is to invoke the
kill-emacs command (see Killing Emacs) so as to shut down Emacs in an orderly fashion; if there are
unsaved changes, this will produce auto-save files
(see Auto-Saving) that the user can use after restarting the
session to restore the unsaved edits.
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.
Some of these special events, such as
Emacs commands by default; others are not bound. If you want to
arrange for a special event to invoke a command, you can do that via
special-event-map. The command you bind to a function key in
that map can then examine the full event which invoked it in
last-input-event. See Special Events.