From: Ryan Johnson<ryanjohn@ece.cmu.edu>
Cc: 7117@debbugs.gnu.org
At this point the symptom is easy enough to understand: sometimes
discard-input gets unlucky and chops the front off of a partly-arrived
escape sequence.
The real question is, why would the command loop encounter errors and
need to discard input at all?
[1] _longjmp()
=>[2] unwind_to_catch()
[3] Fsignal()
[4] xsignal()
[5] xsignal0()
[6] window_scroll()
The only calls to xsignal0 I see in window_scroll (or, rather, in its
subroutines) is to signal Qbeginning_of_buffer or Qend_of_buffer.
From the above, it seems that scrolling past beginning or end of buffer
triggers an error, which I guess is somewhat justifiable.
Indeed. Perhaps we need some infrastructure to ignore errors in this
case (I assume `ignore-errors' won't help). Or maybe we should allow
not to discard input when we signal an error. Or maybe discard-input
should be smarter, and not discard partial escape sequences?
However, on a
very slow connection this morning mouse-clicking between or even within
buffers caused problems. Unfortunately, setting debug-on-error doesn't
seem to catch errors generated from C code.
I could try to break on longjmp over another slow connection, but with
the number of times it gets called for other reasons this would be slow
going...
Ideas?
You could put a breakpoint in Fsignal, and see if the problems with
mouse-clicking within buffers is also caused by signaling an error.