aboutsummaryrefslogtreecommitdiffstats
path: root/src
diff options
context:
space:
mode:
authorKarl Heuer1995-02-22 03:06:08 +0000
committerKarl Heuer1995-02-22 03:06:08 +0000
commit89d8f2460dab366b5066425462b41862c4d405c3 (patch)
tree708ee92cabef384b6b2f07db3aebff10702717da /src
parentcc4c29808c7c90c8011f123bf8320c25de3ae1b6 (diff)
downloademacs-89d8f2460dab366b5066425462b41862c4d405c3.tar.gz
emacs-89d8f2460dab366b5066425462b41862c4d405c3.zip
(struct PERDISPLAY): New member kbd_queue.
Delete obsolescent members kbd_buffer_frame_or_window, kbd_buffer, kbd_fetch_ptr, kbd_store_ptr; these are regular vars again.
Diffstat (limited to 'src')
-rw-r--r--src/lisp.h55
1 files changed, 3 insertions, 52 deletions
diff --git a/src/lisp.h b/src/lisp.h
index bcfa8fa8300..ba2d3d8d415 100644
--- a/src/lisp.h
+++ b/src/lisp.h
@@ -508,62 +508,13 @@ struct PERDISPLAY
508 carry that information itself (i.e. if it was a character). */ 508 carry that information itself (i.e. if it was a character). */
509 Lisp_Object Vlast_event_frame; 509 Lisp_Object Vlast_event_frame;
510 510
511 Lisp_Object kbd_queue;
512
511 /* Placeholder for future vars that will be moved here. */ 513 /* Placeholder for future vars that will be moved here. */
512 Lisp_Object unused[20]; 514 Lisp_Object unused[23];
513 515
514 Lisp_Object this_command_keys; 516 Lisp_Object this_command_keys;
515 517
516 /* Vector to GCPRO the frames and windows mentioned in kbd_buffer.
517
518 The interrupt-level event handlers will never enqueue an event on a
519 frame which is not in Vframe_list, and once an event is dequeued,
520 internal_last_event_frame or the event itself points to the frame.
521 So that's all fine.
522
523 But while the event is sitting in the queue, it's completely
524 unprotected. Suppose the user types one command which will run for
525 a while and then delete a frame, and then types another event at
526 the frame that will be deleted, before the command gets around to
527 it. Suppose there are no references to this frame elsewhere in
528 Emacs, and a GC occurs before the second event is dequeued. Now we
529 have an event referring to a freed frame, which will crash Emacs
530 when it is dequeued.
531
532 Similar things happen when an event on a scroll bar is enqueued; the
533 window may be deleted while the event is in the queue.
534
535 So, we use this vector to protect the frame_or_window field in the
536 event queue. That way, they'll be dequeued as dead frames or
537 windows, but still valid lisp objects.
538
539 If perd->kbd_buffer[i].kind != no_event, then
540 (XVECTOR (perd->kbd_buffer_frame_or_window)->contents[i]
541 == perd->kbd_buffer[i].frame_or_window. */
542 Lisp_Object kbd_buffer_frame_or_window;
543
544 /* Circular buffer for pre-read keyboard input. */
545 struct input_event *kbd_buffer;
546
547 /* Pointer to next available character in kbd_buffer.
548 If kbd_fetch_ptr == kbd_store_ptr, the buffer is empty.
549 This may be kbd_buffer + KBD_BUFFER_SIZE, meaning that the the
550 next available char is in kbd_buffer[0]. */
551 struct input_event *kbd_fetch_ptr;
552
553 /* Pointer to next place to store character in kbd_buffer. This
554 may be kbd_buffer + KBD_BUFFER_SIZE, meaning that the next
555 character should go in kbd_buffer[0]. */
556 volatile struct input_event *kbd_store_ptr;
557
558 /* The above pair of variables forms a "queue empty" flag. When we
559 enqueue a non-hook event, we increment kbd_store_ptr. When we
560 dequeue a non-hook event, we increment kbd_fetch_ptr. We say that
561 there is input available iff the two counters are not equal.
562
563 Why not just have a flag set and cleared by the enqueuing and
564 dequeuing functions? Such a flag could be screwed up by interrupts
565 at inopportune times. */
566
567 int this_command_key_count; 518 int this_command_key_count;
568 519
569 /* Nonzero means echo each character as typed. */ 520 /* Nonzero means echo each character as typed. */