[ < ] | [ > ] | [ << ] | [Plus haut] | [ >> ] | [Top] | [Table des matières] | [Index] | [ ? ] |
A few other event types represent occurrences within the system.
(delete-frame (frame))
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. Their usual meaning is a kind of scroll or zoom.
The element position is a list describing the position of the event, in the same format as used in a mouse-click event.
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 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, 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 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.
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.
To catch a user signal, bind the corresponding event to an interactive
command in the special-event-map
(voir la section Active Keymaps). The
command is called with no arguments, and the specific signal event is
available in last-input-event
. For example:
(defun sigusr-handler () (interactive) (message "Caught signal %S" last-input-event)) (define-key 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) |
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.
[ < ] | [ > ] | [ << ] | [Plus haut] | [ >> ] | [Top] | [Table des matières] | [Index] | [ ? ] |
Ce document a été généré par Eric Reinbold le 13 Octobre 2007 en utilisant texi2html 1.78.