bug#44818: 27.0.91; wedged

[Devon Sean McCullough]

Happy Thanksgiving, hackers in the USA!

Will "so long" catch spammed shells?

What if four or more consecutive ^G quits were to select a
"safe" full frame window or dialog offering a few choices,
e.g., ignore the quits and restore the saved window state,
kill the buffer, select another buffer, read the tutorial,
add overlays to appease redisplay or (eek) quit Emacs?

Would a ^G quit discard unprocessed input?  Is it possible
to time out when unprocessed input languishes for > 50 ms,
in a situation where ^G quit is either ignored or fails to
put the user back in the driver's seat?

Perhaps there's no way to detect when the editor is wedged
and the user has lost control.  One clue might be when the
user types ^G quit many times, but was it a sound check of
the beeper's audio output, or a frustrated user attempting
to regain control of a rogue editor?

                Peace
                        --Devon

P.S.  Some jobs involve a noticeable delay — not ok for redisplay!

(find-file-noselect "src/xdisp.c")    ; 480.5 ms to read the file
(find-file "src/xdisp.c")     ; 1.4 ms to display the buffer

Dead, comatose or entranced?  Best show some sign of life!
E.g., tramp is slower than most remote file interfaces but
users are used it.  Its progress reports should be updated
every second, either a timer or the traditional ETA.