bug#34821: discard_input_tty does not discard pending input, resulting in garbage inserted into the buffer

[Platon Pronko]

I decided to go with async approach, since it is the one that is at least theoretically 
fool-proof. Currently I am trying to debug the problem of "[>65;5600;1c" 
appearing sporadically (10%) of the times in the input buffer. The test case is below:

1. Start the daemon and set it to use async term query:
$ ./src/emacs -Q --fg-daemon --eval "(setq xterm-query-timeout nil)"

2. Launch emacsclient:
$ ./lib-src/emacsclient -t /tmp/test.txt

3. About 1 in 10 times, observe "[>65;5600;1c" appearing in the buffer.


I tracked the problem to src/keyboard.c:read_key_sequence() function. In normal 
case, the following happens:

1. read_ke_sequence() is called for the first time.
2. Current input_decode_map is copied:

indec.map =  indec.map = indec.parent = KVAR (current_kboard, 
Vinput_decode_map);

3. It calls read_char() and blocks.
4. When emacsclient is invoked, read_char() returns the "buffer" object as per 
this comment:

/* When switching to a new tty (with a new keyboard),
  read_char returns the new buffer, rather than -2
  (Bug#5095).  This is because `terminal-init-xterm'
  calls read-char, which eats the wrong_kboard_jmpbuf
  return.  Any better way to fix this? -- cyd */

5. `interrupted_kboard != current_kboard` condition is triggered, this 
read_char() result is discarded and we jump to replay_entire_sequence.
6. read_char() is called again.
7. (terminal-init-xterm) function is invoked.
8. (xterm-query) registeres a handlers for "\e[?" and "\e[>" escape sequences.
9. read_char() returns the "buffer" object the second time.
10. That read_char() result triggers `interrupted_kboard != current_kboard` 
condition again, and we jump to replay_entire_sequence again.
11. Immediately after that jump, we reset the input map: `indec.map =  
indec.map = indec.parent = KVAR (current_kboard, Vinput_decode_map);`, thus 
pulling in handlers from step 8.
12. The subsequent read_char() calls return the next SDA response characters, 
match is found in indec.map and xterm--verision-handler is executed.


For a situation when bug manifests steps 1-8 are the same, however at step 9 
the difference happens - read_char() does not return a buffer, instead it 
returns the first character of the response (0x1b). `interrupted_kboard != 
current_kboard` is still true at that moment, thus this character is discarded. 
Subsequent SDA response characters (0x5b, 0x3e) fail to find a prefix match in 
input_decode_map, and are inserted into the buffer as-is.

I tried changing condition `interrupted_kboard != current_kboard` to 
`interrupted_kboard != current_kboard && BUFFERP(key)`, but that does not 
trigger `goto replay_entire_sequence` and thus new handlers are not pulled in from 
Vinput_decode_map, and so the characters are still inserted into the buffer.

Can somebody please advise me about the right course of action in this case? 
Should I figure out a way to load Vinput_decode_map when new character arrives 
and `interrupted_kboard != current_kboard`? Or should I look into why 
read_char() does not return a buffer the second time?