comparison README.multi-tty @ 83460:dbd791ef90a1

Eliminate wrong_kboard_jmpbuf. * src/keyboard.c (read_char, read_char_minibuf_menu_prompt) (read_key_sequence, read_filtered_event): Eliminate wrong_kboard_jmpbuf. git-archimport-id: [e-mail]--2004/emacs--multi-tty--0--patch-500

83459:8d8bc8469c77

------------

** Understand how `quit_throw_to_read_char' works, and fix any bugs
   that come to light.

** Replace wrong_kboard_jmpbuf with a special return value of
   read_char.  It is absurd that we use setjmp/longjmp just to return
   to the immediate caller.

** See if getcjmp can be eliminated somehow.  Why does Emacs allow
   asynchronous input processing while it's reading input anyway?

** `delete-frame' events are handled by `special-event-map'
   immediately when read by `read_char'.  This is fine but it prevents

   by SIGIO or polling (SIGALRM).  C-g either sets the Vquit_flag,
   signals a 'quit condition (when immediate_quit), or throws to
   `getcjmp' when Emacs was waiting for input when the C-g event
   arrived.)


;;; arch-tag: 8da1619e-2e79-41a8-9ac9-a0485daad17d

83460:dbd791ef90a1

------------

** Understand how `quit_throw_to_read_char' works, and fix any bugs
   that come to light.

** See if getcjmp can be eliminated somehow.  Why does Emacs allow
   asynchronous input processing while it's reading input anyway?

** `delete-frame' events are handled by `special-event-map'
   immediately when read by `read_char'.  This is fine but it prevents

   by SIGIO or polling (SIGALRM).  C-g either sets the Vquit_flag,
   signals a 'quit condition (when immediate_quit), or throws to
   `getcjmp' when Emacs was waiting for input when the C-g event
   arrived.)

-- Replace wrong_kboard_jmpbuf with a special return value of
   read_char.  It is absurd that we use setjmp/longjmp just to return
   to the immediate caller.

   (Done in patch-500.)

;;; arch-tag: 8da1619e-2e79-41a8-9ac9-a0485daad17d