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

[Platon Pronko <platon7pronko@gmail.com>]

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?