bug#7117: 23.2.2 mangles terminal escape sequences

[Eli Zaretskii <eliz@gnu.org>]

> 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.