|
428
|
1 /* Definitions for the new event model;
|
|
|
2 created 16-jul-91 by Jamie Zawinski
|
|
|
3 Copyright (C) 1991, 1992, 1993 Free Software Foundation, Inc.
|
|
788
|
4 Copyright (C) 1995, 1996, 2002 Ben Wing.
|
|
428
|
5
|
|
|
6 This file is part of XEmacs.
|
|
|
7
|
|
|
8 XEmacs is free software; you can redistribute it and/or modify it
|
|
|
9 under the terms of the GNU General Public License as published by the
|
|
|
10 Free Software Foundation; either version 2, or (at your option) any
|
|
|
11 later version.
|
|
|
12
|
|
|
13 XEmacs is distributed in the hope that it will be useful, but WITHOUT
|
|
|
14 ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
|
|
|
15 FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
|
|
|
16 for more details.
|
|
|
17
|
|
|
18 You should have received a copy of the GNU General Public License
|
|
|
19 along with XEmacs; see the file COPYING. If not, write to
|
|
|
20 the Free Software Foundation, Inc., 59 Temple Place - Suite 330,
|
|
|
21 Boston, MA 02111-1307, USA. */
|
|
|
22
|
|
|
23 /* Synched up with: Not in FSF. */
|
|
|
24
|
|
440
|
25 #ifndef INCLUDED_events_h_
|
|
|
26 #define INCLUDED_events_h_
|
|
428
|
27
|
|
|
28 #include "systime.h"
|
|
|
29
|
|
|
30 /* There is one object called an event_stream. This object contains
|
|
|
31 callback functions for doing the window-system-dependent operations
|
|
|
32 that XEmacs requires.
|
|
|
33
|
|
|
34 If XEmacs is compiled with support for X11 and the X Toolkit, then this
|
|
|
35 event_stream structure will contain functions that can cope with input
|
|
|
36 on XEmacs windows on multiple displays, as well as input from dumb tty
|
|
|
37 frames.
|
|
|
38
|
|
|
39 If it is desired to have XEmacs able to open frames on the displays of
|
|
|
40 multiple heterogeneous machines, X11 and SunView, or X11 and NeXT, for
|
|
|
41 example, then it will be necessary to construct an event_stream structure
|
|
|
42 that can cope with the given types. Currently, the only implemented
|
|
440
|
43 event_streams are for dumb-ttys, and for X11 plus dumb-ttys,
|
|
|
44 and for mswindows.
|
|
428
|
45
|
|
|
46 To implement this for one window system is relatively simple.
|
|
|
47 To implement this for multiple window systems is trickier and may
|
|
|
48 not be possible in all situations, but it's been done for X and TTY.
|
|
|
49
|
|
|
50 Note that these callbacks are *NOT* console methods; that's because
|
|
|
51 the routines are not specific to a particular console type but must
|
|
|
52 be able to simultaneously cope with all allowable console types.
|
|
|
53
|
|
|
54 The slots of the event_stream structure:
|
|
|
55
|
|
|
56 next_event_cb A function which fills in an XEmacs_event structure
|
|
|
57 with the next event available. If there is no event
|
|
|
58 available, then this should block.
|
|
|
59
|
|
|
60 IMPORTANT: timer events and especially process
|
|
|
61 events *must not* be returned if there are
|
|
|
62 events of other types available; otherwise you
|
|
|
63 can end up with an infinite loop in Fdiscard_input().
|
|
|
64
|
|
|
65 event_pending_cb A function which says whether there are events to be
|
|
|
66 read. If called with an argument of 0, then this
|
|
|
67 should say whether calling the next_event_cb will
|
|
|
68 block. If called with an argument of 1, then this
|
|
|
69 should say whether there are user-generated events
|
|
|
70 pending (that is, keypresses or mouse-clicks). This
|
|
|
71 is used for redisplay optimization, among other
|
|
|
72 things. On dumb ttys, these two results are the
|
|
|
73 same, but under a window system, they are not.
|
|
|
74
|
|
|
75 If this function is not sure whether there are events
|
|
|
76 to be read, it *must* return 0. Otherwise various
|
|
|
77 undesirable effects will occur, such as redisplay
|
|
|
78 not occurring until the next event occurs.
|
|
|
79
|
|
|
80 handle_magic_event_cb XEmacs calls this with an event structure which
|
|
|
81 contains window-system dependent information that
|
|
|
82 XEmacs doesn't need to know about, but which must
|
|
|
83 happen in order. If the next_event_cb never returns
|
|
|
84 an event of type "magic", this will never be used.
|
|
|
85
|
|
788
|
86 format_magic_event_cb Called with a magic event; print a representation of
|
|
|
87 the innards of the event to PSTREAM.
|
|
|
88
|
|
|
89 compare_magic_event_cb Called with two magic events; return non-zero if
|
|
|
90 the innards of the two are equal, zero otherwise.
|
|
|
91
|
|
|
92 hash_magic_event_cb Called with a magic event; return a hash of the
|
|
|
93 innards of the event.
|
|
|
94
|
|
428
|
95 add_timeout_cb Called with an EMACS_TIME, the absolute time at
|
|
|
96 which a wakeup event should be generated; and a
|
|
|
97 void *, which is an arbitrary value that will be
|
|
|
98 returned in the timeout event. The timeouts
|
|
|
99 generated by this function should be one-shots:
|
|
|
100 they fire once and then disappear. This callback
|
|
|
101 should return an int id-number which uniquely
|
|
|
102 identifies this wakeup. If an implementation
|
|
|
103 doesn't have microseconds or millisecond
|
|
|
104 granularity, it should round up to the closest
|
|
|
105 value it can deal with.
|
|
|
106
|
|
|
107 remove_timeout_cb Called with an int, the id number of a wakeup to
|
|
|
108 discard. This id number must have been returned by
|
|
|
109 the add_timeout_cb. If the given wakeup has
|
|
|
110 already expired, this should do nothing.
|
|
|
111
|
|
|
112 select_process_cb These callbacks tell the underlying implementation to
|
|
|
113 unselect_process_cb add or remove a file descriptor from the list of fds
|
|
|
114 which are polled for inferior-process input. When
|
|
|
115 input becomes available on the given process
|
|
|
116 connection, an event of type "process" should be
|
|
|
117 generated.
|
|
|
118
|
|
|
119 select_console_cb These callbacks tell the underlying implementation
|
|
|
120 unselect_console_cb to add or remove a console from the list of consoles
|
|
|
121 which are polled for user-input.
|
|
|
122
|
|
|
123 select_device_cb These callbacks are used by Unixoid event loops
|
|
|
124 unselect_device_cb (those that use select() and file descriptors and
|
|
|
125 have a separate input fd per device).
|
|
|
126
|
|
853
|
127 create_io_streams_cb These callbacks are called by process code to
|
|
|
128 delete_io_streams_cb create the input and output lstreams which are used
|
|
|
129 for subprocess I/O.
|
|
428
|
130
|
|
|
131 quitp_cb A handler function called from the `QUIT' macro which
|
|
|
132 should check whether the quit character has been
|
|
|
133 typed. On systems with SIGIO, this will not be called
|
|
|
134 unless the `sigio_happened' flag is true (it is set
|
|
|
135 from the SIGIO handler).
|
|
|
136
|
|
|
137 XEmacs has its own event structures, which are distinct from the event
|
|
|
138 structures used by X or any other window system. It is the job of the
|
|
|
139 event_stream layer to translate to this format.
|
|
|
140 */
|
|
|
141
|
|
|
142 /*
|
|
|
143 Stream pairs description
|
|
|
144 ------------------------
|
|
|
145
|
|
|
146 Since there are many possible processes/event loop combinations, the event code
|
|
|
147 is responsible for creating an appropriate lstream type. The process
|
|
|
148 implementation does not care about that implementation.
|
|
|
149
|
|
|
150 The Create stream pair function is passed two void* values, which identify
|
|
|
151 process-dependent 'handles'. The process implementation uses these handles
|
|
|
152 to communicate with child processes. The function must be prepared to receive
|
|
440
|
153 handle types of any process implementation. Since only one process
|
|
428
|
154 implementation exists in a particular XEmacs configuration, preprocessing
|
|
440
|
155 is a means of compiling in the support for the code which deals with particular
|
|
428
|
156 handle types.
|
|
|
157
|
|
|
158 For example, a unixoid type loop, which relies on file descriptors, may be
|
|
|
159 asked to create a pair of streams by a unix-style process implementation.
|
|
|
160 In this case, the handles passed are unix file descriptors, and the code
|
|
|
161 may deal with these directly. Although, the same code may be used on Win32
|
|
|
162 system with X-Windows. In this case, Win32 process implementation passes
|
|
853
|
163 handles of type HANDLE, and the create_io_streams function must call
|
|
428
|
164 appropriate function to get file descriptors given HANDLEs, so that these
|
|
|
165 descriptors may be passed to XtAddInput.
|
|
|
166
|
|
|
167 The handle given may have special denying value, in which case the
|
|
|
168 corresponding lstream should not be created.
|
|
|
169
|
|
|
170 The return value of the function is a unique stream identifier. It is used
|
|
|
171 by processes implementation, in its platform-independent part. There is
|
|
|
172 the get_process_from_usid function, which returns process object given its
|
|
|
173 USID. The event stream is responsible for converting its internal handle
|
|
|
174 type into USID.
|
|
|
175
|
|
|
176 Example is the TTY event stream. When a file descriptor signals input, the
|
|
|
177 event loop must determine process to which the input is destined. Thus,
|
|
|
178 the implementation uses process input stream file descriptor as USID, by
|
|
|
179 simply casting the fd value to USID type.
|
|
|
180
|
|
|
181 There are two special USID values. One, USID_ERROR, indicates that the stream
|
|
|
182 pair cannot be created. The second, USID_DONTHASH, indicates that streams are
|
|
|
183 created, but the event stream does not wish to be able to find the process
|
|
|
184 by its USID. Specifically, if an event stream implementation never calls
|
|
|
185 get_process_from_usid, this value should always be returned, to prevent
|
|
|
186 accumulating useless information on USID to process relationship.
|
|
|
187 */
|
|
|
188
|
|
|
189 /* typedef unsigned int USID; in lisp.h */
|
|
|
190 #define USID_ERROR ((USID)-1)
|
|
|
191 #define USID_DONTHASH ((USID)0)
|
|
|
192
|
|
|
193
|
|
|
194 struct event_stream
|
|
|
195 {
|
|
|
196 int (*event_pending_p) (int);
|
|
440
|
197 void (*next_event_cb) (Lisp_Event *);
|
|
|
198 void (*handle_magic_event_cb) (Lisp_Event *);
|
|
788
|
199 void (*format_magic_event_cb) (Lisp_Event *, Lisp_Object pstream);
|
|
|
200 int (*compare_magic_event_cb) (Lisp_Event *, Lisp_Event *);
|
|
|
201 Hashcode (*hash_magic_event_cb)(Lisp_Event *);
|
|
428
|
202 int (*add_timeout_cb) (EMACS_TIME);
|
|
|
203 void (*remove_timeout_cb) (int);
|
|
|
204 void (*select_console_cb) (struct console *);
|
|
|
205 void (*unselect_console_cb) (struct console *);
|
|
853
|
206 void (*select_process_cb) (Lisp_Process *, int doin, int doerr);
|
|
|
207 void (*unselect_process_cb) (Lisp_Process *, int doin, int doerr);
|
|
428
|
208 void (*quit_p_cb) (void);
|
|
442
|
209 void (*force_event_pending) (struct frame* f);
|
|
853
|
210 void (*create_io_streams_cb) (void* /* inhandle*/, void* /*outhandle*/ ,
|
|
|
211 void * /* errhandle*/,
|
|
428
|
212 Lisp_Object* /* instream */,
|
|
|
213 Lisp_Object* /* outstream */,
|
|
853
|
214 Lisp_Object* /* errstream */,
|
|
|
215 USID * /* in_usid */, USID * /* err_usid */,
|
|
428
|
216 int /* flags */);
|
|
853
|
217 void (*delete_io_streams_cb) (Lisp_Object /* instream */,
|
|
|
218 Lisp_Object /* outstream */,
|
|
|
219 Lisp_Object /* errstream */,
|
|
|
220 USID * /* in_usid */, USID * /* err_usid */);
|
|
442
|
221 int (*current_event_timestamp_cb) (struct console *);
|
|
428
|
222 };
|
|
|
223
|
|
853
|
224 /* Flags for create_io_streams_cb() FLAGS parameter */
|
|
428
|
225 #define STREAM_PTY_FLUSHING 0x0001
|
|
|
226 #define STREAM_NETWORK_CONNECTION 0x0002
|
|
|
227
|
|
|
228 extern struct event_stream *event_stream;
|
|
|
229
|
|
|
230 typedef enum emacs_event_type
|
|
|
231 {
|
|
|
232 empty_event,
|
|
|
233 key_press_event,
|
|
|
234 button_press_event,
|
|
|
235 button_release_event,
|
|
|
236 pointer_motion_event,
|
|
|
237 process_event,
|
|
|
238 timeout_event,
|
|
|
239 magic_event,
|
|
|
240 magic_eval_event,
|
|
|
241 eval_event,
|
|
|
242 misc_user_event,
|
|
|
243 dead_event
|
|
|
244 } emacs_event_type;
|
|
|
245
|
|
|
246 #define first_event_type empty_event
|
|
|
247 #define last_event_type dead_event
|
|
|
248
|
|
771
|
249 #ifdef MULE
|
|
|
250
|
|
|
251 enum alternative_key_chars
|
|
|
252 {
|
|
|
253 KEYCHAR_CURRENT_LANGENV,
|
|
|
254 KEYCHAR_DEFAULT_USER,
|
|
|
255 KEYCHAR_DEFAULT_SYSTEM,
|
|
|
256 KEYCHAR_UNDERLYING_VIRTUAL_KEY_CURRENT_LANGENV,
|
|
|
257 KEYCHAR_UNDERLYING_VIRTUAL_KEY_DEFAULT_USER,
|
|
|
258 KEYCHAR_UNDERLYING_VIRTUAL_KEY_DEFAULT_SYSTEM,
|
|
|
259 KEYCHAR_QWERTY,
|
|
|
260 KEYCHAR_LAST
|
|
|
261 };
|
|
|
262
|
|
|
263 #endif /* MULE */
|
|
428
|
264
|
|
|
265 struct key_data
|
|
|
266 {
|
|
771
|
267 /* What keysym this is; a character or a symbol. */
|
|
|
268 Lisp_Object keysym;
|
|
|
269 /* Modifiers held down when key was pressed: control, meta, etc.
|
|
|
270 Also includes buttons. For many keys, Shift is not a bit; that
|
|
|
271 is implicit in the keyboard layout. */
|
|
|
272 int modifiers;
|
|
|
273 #ifdef MULE
|
|
|
274 /* Alternate character interpretations for this key in different
|
|
|
275 keyboard layouts. This deals with the problem of pressing C-x in
|
|
|
276 the Russian layout (the so-called "Russian C-x problem"), for
|
|
|
277 example: `x' gets mapped to a Cyrillic character, so what do we
|
|
|
278 do? For that matter, what about `C-x b'? What we do is look the
|
|
|
279 key up in the default locales (current language environment, user
|
|
|
280 default, system default), then check to see if the underlying
|
|
|
281 virtual key is alphabetic in the same three defaults, then
|
|
|
282 finally check US ASCII. We ignore the underlying virtual key for
|
|
|
283 the current layout to avoid the problem of a French speaker
|
|
|
284 (AZERTY layout) who temporarily switches to Russian: The virtual
|
|
|
285 keys underlying Russian are US-ASCII, so what the French speaker
|
|
|
286 things of as C-a (the key just to the right of TAB) appears as
|
|
|
287 C-q. (#### We should probably ignore the current char and look
|
|
|
288 *ONLY* in alt_keychars for all control keys. What about the
|
|
|
289 English speaker who temporarily switches to the French layout and
|
|
|
290 finds C-q mapped to C-a?) */
|
|
867
|
291 Ichar alt_keychars[KEYCHAR_LAST];
|
|
771
|
292 #endif /* MULE */
|
|
428
|
293 };
|
|
|
294
|
|
|
295 struct button_data
|
|
|
296 {
|
|
771
|
297 /* What button went down or up. */
|
|
|
298 int button;
|
|
|
299 /* Bucky-bits on that button: shift, control, meta, etc. Also
|
|
|
300 includes other buttons (not the one pressed). */
|
|
|
301 int modifiers;
|
|
|
302 /* Where it was at the button-state-change (in pixels). */
|
|
|
303 int x, y;
|
|
428
|
304 };
|
|
|
305
|
|
|
306 struct motion_data
|
|
|
307 {
|
|
771
|
308 /* Where it was after it moved (in pixels). */
|
|
|
309 int x, y;
|
|
|
310 /* Bucky-bits down when the motion was detected. */
|
|
|
311 int modifiers;
|
|
428
|
312 };
|
|
|
313
|
|
|
314 struct process_data
|
|
|
315 {
|
|
771
|
316 /* the XEmacs "process" object in question */
|
|
|
317 Lisp_Object process;
|
|
428
|
318 };
|
|
|
319
|
|
|
320 struct timeout_data
|
|
|
321 {
|
|
771
|
322 /*
|
|
|
323 interval_id The ID returned when the associated call to
|
|
|
324 add_timeout_cb() was made
|
|
|
325 ------ the rest of the fields are filled in by XEmacs -----
|
|
|
326 id_number The XEmacs timeout ID for this timeout (more
|
|
|
327 than one timeout event can have the same value
|
|
|
328 here, since XEmacs timeouts, as opposed to
|
|
|
329 add_timeout_cb() timeouts, can resignal
|
|
|
330 themselves)
|
|
|
331 function An elisp function to call when this timeout is
|
|
|
332 processed.
|
|
|
333 object The object passed to that function.
|
|
|
334 */
|
|
|
335 int interval_id;
|
|
|
336 int id_number;
|
|
|
337 Lisp_Object function;
|
|
|
338 Lisp_Object object;
|
|
428
|
339 };
|
|
|
340
|
|
|
341 struct eval_data
|
|
|
342 {
|
|
771
|
343 /* This kind of event is used internally; sometimes the window system
|
|
|
344 interface would like to inform XEmacs of some user action (such as
|
|
|
345 focusing on another frame) but needs that to happen synchronously
|
|
|
346 with the other user input, like keypresses. This is useful when
|
|
|
347 events are reported through callbacks rather than in the standard
|
|
|
348 event stream.
|
|
|
349
|
|
|
350 function An elisp function to call with this event object.
|
|
|
351 object Argument of function.
|
|
|
352 */
|
|
|
353 Lisp_Object function;
|
|
|
354 Lisp_Object object;
|
|
428
|
355 };
|
|
|
356
|
|
|
357 struct misc_user_data
|
|
|
358 {
|
|
771
|
359 /* #### The misc-user type is serious junk. It should be separated
|
|
|
360 out into different events. There's no reason to create
|
|
|
361 sub-subtypes of events.
|
|
|
362
|
|
|
363 function An elisp function to call with this event object.
|
|
|
364 object Argument of function.
|
|
|
365 button What button went down or up.
|
|
|
366 modifiers Bucky-bits on that button: shift, control, meta, etc.
|
|
|
367 x, y Where it was at the button-state-change (in pixels).
|
|
|
368 This is similar to an eval_event, except that it is
|
|
|
369 generated by user actions: selections in the
|
|
|
370 menubar, scrollbar actions, or drag and drop actions.
|
|
|
371 It is a "command" event, like key and mouse presses
|
|
|
372 (and unlike mouse motion, process output, and enter
|
|
|
373 and leave window hooks). In many ways, eval_events
|
|
|
374 are not the same as keypresses or misc_user_events.
|
|
|
375 The button, modifiers, x, and y parts are only used
|
|
|
376 by the XEmacs Drag'n'Drop system. Don't depend on their
|
|
|
377 values for other types of misc_user_events.
|
|
|
378 */
|
|
|
379 Lisp_Object function;
|
|
|
380 Lisp_Object object;
|
|
|
381 int button;
|
|
|
382 int modifiers;
|
|
|
383 int x, y;
|
|
428
|
384 };
|
|
|
385
|
|
|
386 struct magic_eval_data
|
|
|
387 {
|
|
771
|
388 /* This is like an eval event but its contents are not
|
|
|
389 Lisp-accessible. This allows for "internal eval events" that call
|
|
|
390 non-Lisp-accessible functions. Externally, a magic_eval_event just
|
|
|
391 appears as a magic_event; the Lisp programmer need not know
|
|
|
392 anything more.
|
|
|
393
|
|
|
394 internal_function An unexported function to call with this event
|
|
|
395 object. This allows eval events to call internal
|
|
|
396 functions. For a normal eval event, this field
|
|
|
397 will always be 0.
|
|
|
398 object Argument of function.
|
|
|
399
|
|
|
400 */
|
|
|
401 void (*internal_function) (Lisp_Object);
|
|
|
402 Lisp_Object object;
|
|
428
|
403 };
|
|
|
404
|
|
|
405 #if defined (HAVE_X_WINDOWS) && defined(emacs)
|
|
|
406 # include <X11/Xlib.h>
|
|
|
407 #endif
|
|
|
408
|
|
462
|
409 #ifdef HAVE_GTK
|
|
|
410 #include <gdk/gdk.h>
|
|
|
411 #endif
|
|
|
412
|
|
428
|
413 union magic_data
|
|
|
414 {
|
|
771
|
415 /* No user-serviceable parts within. This is for things like
|
|
|
416 KeymapNotify and ExposeRegion events and so on that XEmacs itself
|
|
|
417 doesn't care about, but which it must do something with for proper
|
|
|
418 interaction with the window system.
|
|
|
419
|
|
|
420 Magic_events are handled somewhat asynchronously, just like
|
|
|
421 subprocess filters. However, occasionally a magic_event needs to
|
|
|
422 be handled synchronously; in that case, the asynchronous handling
|
|
|
423 of the magic_event will push an eval_event back onto the queue,
|
|
|
424 which will be handled synchronously later. This is one of the
|
|
|
425 reasons why eval_events exist; I'm not entirely happy with this
|
|
|
426 aspect of this event model.
|
|
|
427 */
|
|
|
428
|
|
462
|
429 #ifdef HAVE_GTK
|
|
771
|
430 GdkEvent underlying_gdk_event;
|
|
462
|
431 #endif
|
|
428
|
432 #ifdef HAVE_X_WINDOWS
|
|
771
|
433 XEvent underlying_x_event;
|
|
428
|
434 #endif
|
|
|
435 #ifdef HAVE_MS_WINDOWS
|
|
771
|
436 int underlying_mswindows_event;
|
|
428
|
437 #endif
|
|
|
438 };
|
|
|
439
|
|
|
440 struct Lisp_Timeout
|
|
|
441 {
|
|
432
|
442 struct lcrecord_header header;
|
|
428
|
443 int id; /* Id we use to identify the timeout over its lifetime */
|
|
|
444 int interval_id; /* Id for this particular interval; this may
|
|
771
|
445 be different each time the timeout is
|
|
|
446 signalled.*/
|
|
428
|
447 Lisp_Object function, object; /* Function and object associated
|
|
771
|
448 with timeout. */
|
|
428
|
449 EMACS_TIME next_signal_time; /* Absolute time when the timeout
|
|
771
|
450 is next going to be signalled. */
|
|
428
|
451 unsigned int resignal_msecs; /* How far after the next timeout
|
|
771
|
452 should the one after that
|
|
|
453 occur? */
|
|
428
|
454 };
|
|
440
|
455 typedef struct Lisp_Timeout Lisp_Timeout;
|
|
428
|
456
|
|
440
|
457 DECLARE_LRECORD (timeout, Lisp_Timeout);
|
|
|
458 #define XTIMEOUT(x) XRECORD (x, timeout, Lisp_Timeout)
|
|
617
|
459 #define wrap_timeout(p) wrap_record (p, timeout)
|
|
428
|
460 #define TIMEOUTP(x) RECORDP (x, timeout)
|
|
|
461 #define CHECK_TIMEOUT(x) CHECK_RECORD (x, timeout)
|
|
|
462 #define CONCHECK_TIMEOUT(x) CONCHECK_RECORD (x, timeout)
|
|
|
463
|
|
|
464 struct Lisp_Event
|
|
|
465 {
|
|
|
466 /* header->next (aka XEVENT_NEXT ()) is used as follows:
|
|
|
467 - For dead events, this is the next dead one.
|
|
|
468 - For events on the command_event_queue, the next one on the queue.
|
|
|
469 - Likewise for events chained in the command builder.
|
|
|
470 - Otherwise it's Qnil.
|
|
|
471 */
|
|
|
472 struct lrecord_header lheader;
|
|
771
|
473 Lisp_Object next;
|
|
|
474 emacs_event_type event_type;
|
|
|
475
|
|
|
476 /* Where this event occurred on. This will be a frame, device,
|
|
|
477 console, or nil, depending on the event type. It is important
|
|
|
478 that an object of a more specific type than is actually generated
|
|
|
479 is not substituted -- e.g. there should not be a frame inserted
|
|
|
480 when a key-press event occurs, because events on dead channels
|
|
|
481 are automatically ignored.
|
|
|
482
|
|
|
483 Specifically:
|
|
|
484
|
|
|
485 -- for button and mouse-motion events, channel will be a
|
|
|
486 frame. (The translation to a window occurs later.)
|
|
|
487
|
|
|
488 -- for keyboard events, channel will be a console. Note that
|
|
|
489 fake keyboard events (generated by `character-to-event' or
|
|
|
490 something that calls this, such as macros) need to have the
|
|
|
491 selected console stored into them when the event is created.
|
|
|
492 This is so that the correct console-local variables (e.g. the
|
|
|
493 command builder) will get affected.
|
|
|
494
|
|
|
495 -- for timer, process, magic-eval, and eval events, channel will
|
|
|
496 be nil.
|
|
|
497
|
|
|
498 -- for misc-user events, channel will be a frame.
|
|
|
499
|
|
|
500 -- for magic events, channel will be a frame (usually) or a
|
|
|
501 device. */
|
|
|
502 Lisp_Object channel;
|
|
|
503
|
|
|
504 /* When this event occurred -- if not known, this is made up. ####
|
|
|
505 All timestamps should be measured as milliseconds since XEmacs
|
|
|
506 started. Currently they are raw server timestamps. (The X
|
|
|
507 protocol doesn't provide any easy way of translating between
|
|
|
508 server time and real process time; yuck.) */
|
|
|
509
|
|
|
510 unsigned int timestamp;
|
|
428
|
511 union
|
|
|
512 {
|
|
771
|
513 struct key_data key;
|
|
|
514 struct button_data button;
|
|
|
515 struct motion_data motion;
|
|
|
516 struct process_data process;
|
|
|
517 struct timeout_data timeout;
|
|
|
518 struct eval_data eval; /* misc_user_event no longer uses this */
|
|
|
519 struct misc_user_data misc; /* because it needs position information */
|
|
|
520 union magic_data magic;
|
|
|
521 struct magic_eval_data magic_eval;
|
|
428
|
522 } event;
|
|
|
523 };
|
|
|
524
|
|
440
|
525 DECLARE_LRECORD (event, Lisp_Event);
|
|
|
526 #define XEVENT(x) XRECORD (x, event, Lisp_Event)
|
|
617
|
527 #define wrap_event(p) wrap_record (p, event)
|
|
428
|
528 #define EVENTP(x) RECORDP (x, event)
|
|
|
529 #define CHECK_EVENT(x) CHECK_RECORD (x, event)
|
|
|
530 #define CONCHECK_EVENT(x) CONCHECK_RECORD (x, event)
|
|
|
531
|
|
|
532 DECLARE_LRECORD (command_builder, struct command_builder);
|
|
|
533
|
|
|
534 #define EVENT_CHANNEL(a) ((a)->channel)
|
|
|
535 #define EVENT_TYPE(a) ((a)->event_type)
|
|
|
536 #define XEVENT_TYPE(a) (XEVENT (a)->event_type)
|
|
|
537 #define EVENT_NEXT(a) ((a)->next)
|
|
|
538 #define XEVENT_NEXT(e) (XEVENT (e)->next)
|
|
|
539 #define XSET_EVENT_NEXT(e, n) do { (XEVENT (e)->next = (n)); } while (0)
|
|
|
540
|
|
|
541 #define EVENT_CHAIN_LOOP(event, chain) \
|
|
|
542 for (event = chain; !NILP (event); event = XEVENT_NEXT (event))
|
|
|
543
|
|
|
544 #define EVENT_LIVE_P(a) (EVENT_TYPE (a) != dead_event)
|
|
|
545
|
|
771
|
546 #define CHECK_LIVE_EVENT(x) do { \
|
|
|
547 CHECK_EVENT (x); \
|
|
|
548 if (! EVENT_LIVE_P (XEVENT (x))) \
|
|
|
549 dead_wrong_type_argument (Qevent_live_p, (x)); \
|
|
428
|
550 } while (0)
|
|
771
|
551 #define CONCHECK_LIVE_EVENT(x) do { \
|
|
|
552 CONCHECK_EVENT (x); \
|
|
|
553 if (! EVENT_LIVE_P (XEVENT (x))) \
|
|
|
554 x = wrong_type_argument (Qevent_live_p, (x)); \
|
|
428
|
555 } while (0)
|
|
|
556
|
|
|
557
|
|
|
558 EXFUN (Fcharacter_to_event, 4);
|
|
|
559 EXFUN (Fdeallocate_event, 1);
|
|
|
560 EXFUN (Fevent_glyph_extent, 1);
|
|
|
561 EXFUN (Fevent_modeline_position, 1);
|
|
|
562 EXFUN (Fevent_over_modeline_p, 1);
|
|
|
563 EXFUN (Fevent_over_toolbar_p, 1);
|
|
|
564 EXFUN (Fevent_over_vertical_divider_p, 1);
|
|
|
565 EXFUN (Fevent_point, 1);
|
|
|
566 EXFUN (Fevent_window, 1);
|
|
|
567 EXFUN (Fmake_event, 2);
|
|
|
568
|
|
|
569 extern Lisp_Object QKbackspace, QKdelete, QKescape, QKlinefeed, QKreturn;
|
|
|
570 extern Lisp_Object QKspace, QKtab, Qmouse_event_p, Vcharacter_set_property;
|
|
|
571 extern Lisp_Object Qcancel_mode_internal;
|
|
444
|
572 extern Lisp_Object Vmodifier_keys_sticky_time;
|
|
428
|
573
|
|
502
|
574 /* The modifiers XEmacs knows about; these appear in key and button events. */
|
|
|
575
|
|
771
|
576 #define XEMACS_MOD_CONTROL (1<<0)
|
|
|
577 #define XEMACS_MOD_META (1<<1)
|
|
|
578 #define XEMACS_MOD_SUPER (1<<2)
|
|
|
579 #define XEMACS_MOD_HYPER (1<<3)
|
|
|
580 #define XEMACS_MOD_ALT (1<<4)
|
|
|
581 #define XEMACS_MOD_SHIFT (1<<5) /* not used for dual-case characters */
|
|
|
582 #define XEMACS_MOD_BUTTON1 (1<<6)
|
|
|
583 #define XEMACS_MOD_BUTTON2 (1<<7)
|
|
|
584 #define XEMACS_MOD_BUTTON3 (1<<8)
|
|
|
585 #define XEMACS_MOD_BUTTON4 (1<<9)
|
|
|
586 #define XEMACS_MOD_BUTTON5 (1<<10)
|
|
502
|
587
|
|
|
588 /* Note: under X Windows, XEMACS_MOD_ALT is generated by the Alt key
|
|
|
589 if there are both Alt and Meta keys. If there are no Meta keys,
|
|
|
590 then Alt generates XEMACS_MOD_META instead.
|
|
428
|
591 */
|
|
|
592
|
|
|
593 /* Maybe this should be trickier */
|
|
|
594 #define KEYSYM(x) (intern (x))
|
|
|
595
|
|
|
596 /* from events.c */
|
|
793
|
597 void format_event_object (Eistring *buf, Lisp_Event *event, int brief);
|
|
867
|
598 void character_to_event (Ichar c, Lisp_Event *event,
|
|
771
|
599 struct console *con,
|
|
|
600 int use_console_meta_flag,
|
|
|
601 int do_backspace_mapping);
|
|
440
|
602 void zero_event (Lisp_Event *e);
|
|
428
|
603 void deallocate_event_chain (Lisp_Object event);
|
|
|
604 Lisp_Object event_chain_tail (Lisp_Object event);
|
|
|
605 void enqueue_event (Lisp_Object event, Lisp_Object *head, Lisp_Object *tail);
|
|
|
606 Lisp_Object dequeue_event (Lisp_Object *head, Lisp_Object *tail);
|
|
|
607 void enqueue_event_chain (Lisp_Object event_chain, Lisp_Object *head,
|
|
771
|
608 Lisp_Object *tail);
|
|
428
|
609 int event_chain_count (Lisp_Object event_chain);
|
|
771
|
610 Lisp_Object transfer_event_chain_pointer (Lisp_Object pointer,
|
|
|
611 Lisp_Object old_chain,
|
|
|
612 Lisp_Object new_chain);
|
|
428
|
613 void nth_of_key_sequence_as_event (Lisp_Object seq, int n, Lisp_Object event);
|
|
|
614 Lisp_Object key_sequence_to_event_chain (Lisp_Object seq);
|
|
|
615 Lisp_Object event_chain_find_previous (Lisp_Object event_chain,
|
|
771
|
616 Lisp_Object event);
|
|
428
|
617 Lisp_Object event_chain_nth (Lisp_Object event_chain, int n);
|
|
|
618 Lisp_Object copy_event_chain (Lisp_Object event_chain);
|
|
|
619 /* True if this is a non-internal event
|
|
|
620 (keyboard press, menu, scrollbar, mouse button) */
|
|
|
621 int command_event_p (Lisp_Object event);
|
|
440
|
622 void define_self_inserting_symbol (Lisp_Object, Lisp_Object);
|
|
867
|
623 Ichar event_to_character (Lisp_Event *, int, int, int);
|
|
428
|
624 struct console *event_console_or_selected (Lisp_Object event);
|
|
|
625
|
|
|
626 /* from event-stream.c */
|
|
771
|
627 Lisp_Object allocate_command_builder (Lisp_Object console, int with_echo_buf);
|
|
428
|
628 void enqueue_magic_eval_event (void (*fun) (Lisp_Object), Lisp_Object object);
|
|
440
|
629 void event_stream_handle_magic_event (Lisp_Event *event);
|
|
788
|
630 void event_stream_format_magic_event (Lisp_Event *event, Lisp_Object pstream);
|
|
|
631 int event_stream_compare_magic_event (Lisp_Event *e1, Lisp_Event *e2);
|
|
|
632 Hashcode event_stream_hash_magic_event (Lisp_Event *e);
|
|
428
|
633 void event_stream_select_console (struct console *con);
|
|
|
634 void event_stream_unselect_console (struct console *con);
|
|
853
|
635 void event_stream_select_process (Lisp_Process *proc, int doin, int doerr);
|
|
|
636 void event_stream_unselect_process (Lisp_Process *proc, int doin, int doerr);
|
|
|
637 void event_stream_create_io_streams (void* inhandle, void* outhandle,
|
|
|
638 void *errhandle, Lisp_Object* instream,
|
|
|
639 Lisp_Object* outstream,
|
|
|
640 Lisp_Object* errstream,
|
|
|
641 USID* in_usid,
|
|
|
642 USID* err_usid,
|
|
|
643 int flags);
|
|
|
644 void event_stream_delete_io_streams (Lisp_Object instream,
|
|
|
645 Lisp_Object outstream,
|
|
|
646 Lisp_Object errstream,
|
|
|
647 USID* in_usid,
|
|
|
648 USID* err_usid);
|
|
428
|
649 void event_stream_quit_p (void);
|
|
853
|
650 void run_pre_idle_hook (void);
|
|
428
|
651
|
|
|
652 struct low_level_timeout
|
|
|
653 {
|
|
|
654 int id;
|
|
|
655 EMACS_TIME time;
|
|
|
656 struct low_level_timeout *next;
|
|
|
657 };
|
|
|
658
|
|
|
659 int add_low_level_timeout (struct low_level_timeout **timeout_list,
|
|
771
|
660 EMACS_TIME thyme);
|
|
428
|
661 void remove_low_level_timeout (struct low_level_timeout **timeout_list,
|
|
771
|
662 int id);
|
|
428
|
663 int get_low_level_timeout_interval (struct low_level_timeout *
|
|
771
|
664 timeout_list, EMACS_TIME *interval);
|
|
428
|
665 int pop_low_level_timeout (struct low_level_timeout **timeout_list,
|
|
771
|
666 EMACS_TIME *time_out);
|
|
428
|
667 int event_stream_generate_wakeup (unsigned int milliseconds,
|
|
771
|
668 unsigned int vanilliseconds,
|
|
|
669 Lisp_Object function,
|
|
|
670 Lisp_Object object,
|
|
|
671 int async_p);
|
|
593
|
672 int event_stream_resignal_wakeup (int interval_id, int async_p,
|
|
771
|
673 Lisp_Object *function, Lisp_Object *object);
|
|
428
|
674 void event_stream_disable_wakeup (int id, int async_p);
|
|
|
675
|
|
593
|
676 /* from signal.c */
|
|
|
677 int signal_add_async_interval_timeout (EMACS_TIME thyme);
|
|
|
678 void signal_remove_async_interval_timeout (int id);
|
|
428
|
679
|
|
|
680 /* from event-stream.c -- focus sanity */
|
|
|
681 extern int focus_follows_mouse;
|
|
|
682 void investigate_frame_change (void);
|
|
|
683
|
|
|
684 void emacs_handle_focus_change_preliminary (Lisp_Object frame_inp_and_dev);
|
|
|
685 void emacs_handle_focus_change_final (Lisp_Object frame_inp_and_dev);
|
|
|
686
|
|
|
687 Lisp_Object extract_this_command_keys_nth_mouse_event (int n);
|
|
|
688 Lisp_Object extract_vector_nth_mouse_event (Lisp_Object vector, int n);
|
|
|
689
|
|
|
690 void single_console_state (void);
|
|
|
691 void any_console_state (void);
|
|
|
692 int in_single_console_state (void);
|
|
|
693
|
|
|
694 extern int emacs_is_blocking;
|
|
|
695
|
|
|
696 extern volatile int sigint_happened;
|
|
|
697
|
|
|
698 #ifdef HAVE_UNIXOID_EVENT_LOOP
|
|
|
699 /* from event-unixoid.c */
|
|
|
700
|
|
|
701 /* Ceci n'est pas un pipe. */
|
|
|
702 extern int signal_event_pipe[];
|
|
|
703
|
|
|
704 void signal_fake_event (void);
|
|
|
705 void drain_signal_event_pipe (void);
|
|
|
706
|
|
|
707 extern int fake_event_occurred;
|
|
|
708
|
|
|
709 int event_stream_unixoid_select_console (struct console *con);
|
|
|
710 int event_stream_unixoid_unselect_console (struct console *con);
|
|
853
|
711 void event_stream_unixoid_select_process (Lisp_Process *proc, int doin,
|
|
|
712 int doerr, int *infd, int *errfd);
|
|
|
713 void event_stream_unixoid_unselect_process (Lisp_Process *proc, int doin,
|
|
|
714 int doerr, int *infd, int *errfd);
|
|
440
|
715 int read_event_from_tty_or_stream_desc (Lisp_Event *event,
|
|
771
|
716 struct console *con);
|
|
853
|
717 void event_stream_unixoid_create_io_streams (void* inhandle, void* outhandle,
|
|
|
718 void *errhandle,
|
|
|
719 Lisp_Object* instream,
|
|
|
720 Lisp_Object* outstream,
|
|
|
721 Lisp_Object* errstream,
|
|
|
722 USID* in_usid,
|
|
|
723 USID* err_usid,
|
|
|
724 int flags);
|
|
|
725 void event_stream_unixoid_delete_io_streams (Lisp_Object instream,
|
|
|
726 Lisp_Object outstream,
|
|
|
727 Lisp_Object errstream,
|
|
|
728 USID* in_usid,
|
|
|
729 USID* err_usid);
|
|
428
|
730
|
|
|
731 /* Beware: this evil macro evaluates its arg many times */
|
|
|
732 #define FD_TO_USID(fd) ((fd)==0 ? (USID)999999 : ((fd)<0 ? USID_DONTHASH : (USID)(fd)))
|
|
|
733
|
|
|
734 #endif /* HAVE_UNIXOID_EVENT_LOOP */
|
|
|
735
|
|
|
736 /* Define this if you want the tty event stream to be used when the
|
|
|
737 first console is tty, even if HAVE_X_WINDOWS is defined */
|
|
|
738 /* #define DEBUG_TTY_EVENT_STREAM */
|
|
|
739
|
|
|
740
|
|
442
|
741 /* #### a hack, until accelerator shit is cleaned up */
|
|
|
742
|
|
|
743 /* This structure is what we use to encapsulate the state of a command sequence
|
|
|
744 being composed; key events are executed by adding themselves to the command
|
|
|
745 builder; if the command builder is then complete (does not still represent
|
|
|
746 a prefix key sequence) it executes the corresponding command.
|
|
|
747 */
|
|
|
748 struct command_builder
|
|
|
749 {
|
|
|
750 struct lcrecord_header header;
|
|
|
751 Lisp_Object console; /* back pointer to the console this command
|
|
771
|
752 builder is for */
|
|
|
753 #if 0
|
|
|
754 /* #### Not implemented: nil, or an event representing the first
|
|
|
755 event read after the last command completed. Threaded. */
|
|
442
|
756 Lisp_Object prefix_events;
|
|
771
|
757 #endif /* 0 */
|
|
|
758 /* nil, or an event chain representing the events in the current
|
|
|
759 keymap-lookup sequence. NOTE: All events in the chain MUST be
|
|
|
760 freshly allocated, with no pointers to them elsewhere. */
|
|
442
|
761 Lisp_Object current_events;
|
|
771
|
762 /* Last elt of current_events */
|
|
442
|
763 Lisp_Object most_current_event;
|
|
771
|
764 /* Last elt before function map code took over. What this means is:
|
|
442
|
765 All prefixes up to (but not including) this event have non-nil
|
|
|
766 bindings, but the prefix including this event has a nil binding.
|
|
|
767 Any events in the chain after this one were read solely because
|
|
|
768 we're part of a possible function key. If we end up with
|
|
|
769 something that's not part of a possible function key, we have to
|
|
|
770 unread all of those events. */
|
|
|
771 Lisp_Object last_non_munged_event;
|
|
|
772 /* One set of values for function-key-map, one for key-translation-map */
|
|
|
773 struct munging_key_translation
|
|
|
774 {
|
|
|
775 /* First event that can begin a possible function key sequence
|
|
|
776 (to be translated according to function-key-map). Normally
|
|
|
777 this is the first event in the chain. However, once we've
|
|
|
778 translated a sequence through function-key-map, this will point
|
|
|
779 to the first event after the translated sequence: we don't ever
|
|
|
780 want to translate any events twice through function-key-map, or
|
|
|
781 things could get really screwed up (e.g. if the user created a
|
|
|
782 translation loop). If this is nil, then the next-read event is
|
|
|
783 the first that can begin a function key sequence. */
|
|
|
784 Lisp_Object first_mungeable_event;
|
|
|
785 } munge_me[2];
|
|
|
786
|
|
867
|
787 Ibyte *echo_buf;
|
|
442
|
788 Bytecount echo_buf_length; /* size of echo_buf */
|
|
|
789 Bytecount echo_buf_index; /* index into echo_buf
|
|
771
|
790 * -1 before doing echoing for new cmd */
|
|
442
|
791 /* Self-insert-command is magic in that it doesn't always push an undo-
|
|
|
792 boundary: up to 20 consecutive self-inserts can happen before an undo-
|
|
|
793 boundary is pushed. This variable is that counter.
|
|
|
794 */
|
|
|
795 int self_insert_countdown;
|
|
|
796 };
|
|
|
797
|
|
440
|
798 #endif /* INCLUDED_events_h_ */
|
