event_stream layer to translate to this format.
NOTE: #### All timestamps should be measured as milliseconds since XEmacs
- started. Currently many or most events have a 0 as their
- timestamp value, and for other timestamps, they are raw server
- timestamps. (The X protocol doesn't provide any easy way of
- translating between server time and real process time; yuck.)
+ started. Currently they are raw server timestamps. (The X protocol
+ doesn't provide any easy way of translating between server time and
+ real process time; yuck.)
Every event type has the following structures:
If this is an integer, it will be in the printing
ASCII range: >32 and <127.
modifiers Bucky-bits on that key: control, meta, etc.
+ Also includes buttons.
For many keys, Shift is not a bit; that is implicit
in the keyboard layout.
button_release_event
button What button went down or up.
modifiers Bucky-bits on that button: shift, control, meta, etc.
+ Also includes other buttons (not the one pressed).
x, y Where it was at the button-state-change (in pixels).
pointer_motion_event
x, y Where it was after it moved (in pixels).
modifiers Bucky-bits down when the motion was detected.
- (Possibly not all window systems will provide this?)
process_event
process the XEmacs "process" object in question
void (*select_process_cb) (Lisp_Process *);
void (*unselect_process_cb) (Lisp_Process *);
void (*quit_p_cb) (void);
+ void (*force_event_pending) (struct frame* f);
USID (*create_stream_pair_cb) (void* /* inhandle*/, void* /*outhandle*/ ,
Lisp_Object* /* instream */,
Lisp_Object* /* outstream */,
int /* flags */);
USID (*delete_stream_pair_cb) (Lisp_Object /* instream */,
Lisp_Object /* outstream */);
+ int (*current_event_timestamp_cb) (struct console *);
};
/* Flags for create_stream_pair_cb() FLAGS parameter */
struct key_data
{
Lisp_Object keysym;
- unsigned char modifiers;
+ int modifiers;
};
struct button_data
{
int button;
- unsigned char modifiers;
+ int modifiers;
int x, y;
};
struct motion_data
{
int x, y;
- unsigned char modifiers;
+ int modifiers;
};
struct process_data
Lisp_Object function;
Lisp_Object object;
int button;
- unsigned char modifiers;
+ int modifiers;
int x, y;
};
# include <X11/Xlib.h>
#endif
+#ifdef HAVE_GTK
+#include <gdk/gdk.h>
+#endif
+
union magic_data
{
#ifdef HAVE_TTY
char underlying_tty_event;
#endif
+#ifdef HAVE_GTK
+ GdkEvent underlying_gdk_event;
+#endif
#ifdef HAVE_X_WINDOWS
XEvent underlying_x_event;
#endif
extern Lisp_Object QKbackspace, QKdelete, QKescape, QKlinefeed, QKreturn;
extern Lisp_Object QKspace, QKtab, Qmouse_event_p, Vcharacter_set_property;
extern Lisp_Object Qcancel_mode_internal;
+extern Lisp_Object Vmodifier_keys_sticky_time;
-/* Note: under X Windows, MOD_ALT is generated by the Alt key if there are
+/* Note: under X Windows, XEMACS_MOD_ALT is generated by the Alt key if there are
both Alt and Meta keys. If there are no Meta keys, then Alt generates
- MOD_META instead.
+ XEMACS_MOD_META instead.
*/
#ifdef emacs
#endif /* emacs */
+/* #### a hack, until accelerator shit is cleaned up */
+
+/* This structure is what we use to encapsulate the state of a command sequence
+ being composed; key events are executed by adding themselves to the command
+ builder; if the command builder is then complete (does not still represent
+ a prefix key sequence) it executes the corresponding command.
+ */
+struct command_builder
+{
+ struct lcrecord_header header;
+ Lisp_Object console; /* back pointer to the console this command
+ builder is for */
+ /* Qnil, or a Lisp_Event representing the first event read
+ * after the last command completed. Threaded. */
+ /* #### NYI */
+ Lisp_Object prefix_events;
+ /* Qnil, or a Lisp_Event representing event in the current
+ * keymap-lookup sequence. Subsequent events are threaded via
+ * the event's next slot */
+ Lisp_Object current_events;
+ /* Last elt of above */
+ Lisp_Object most_current_event;
+ /* Last elt before function map code took over. What this means is:
+ All prefixes up to (but not including) this event have non-nil
+ bindings, but the prefix including this event has a nil binding.
+ Any events in the chain after this one were read solely because
+ we're part of a possible function key. If we end up with
+ something that's not part of a possible function key, we have to
+ unread all of those events. */
+ Lisp_Object last_non_munged_event;
+ /* One set of values for function-key-map, one for key-translation-map */
+ struct munging_key_translation
+ {
+ /* First event that can begin a possible function key sequence
+ (to be translated according to function-key-map). Normally
+ this is the first event in the chain. However, once we've
+ translated a sequence through function-key-map, this will point
+ to the first event after the translated sequence: we don't ever
+ want to translate any events twice through function-key-map, or
+ things could get really screwed up (e.g. if the user created a
+ translation loop). If this is nil, then the next-read event is
+ the first that can begin a function key sequence. */
+ Lisp_Object first_mungeable_event;
+ } munge_me[2];
+
+ Bufbyte *echo_buf;
+ Bytecount echo_buf_length; /* size of echo_buf */
+ Bytecount echo_buf_index; /* index into echo_buf
+ * -1 before doing echoing for new cmd */
+ /* Self-insert-command is magic in that it doesn't always push an undo-
+ boundary: up to 20 consecutive self-inserts can happen before an undo-
+ boundary is pushed. This variable is that counter.
+ */
+ int self_insert_countdown;
+};
+
#endif /* INCLUDED_events_h_ */
projects / chise / xemacs-chise.git.1 / blobdiff