Re: Additional xterm-mouse cleanup

[Jared Finder]

On 2021-02-24 7:56 pm, Stefan Monnier wrote:
> > Ah, got it. I agree, it is mostly straightforward. To do this properly
> >  required making an assumption that .timestamp=0 for 
> > SELECT_WINDOW_EVENT is
> >  ok. Looking through the C code, I don't see any location that reads
> >  .timestamp for the SELECT_WINDOW_EVENT, so I make it uniformly
> >  0 throughout.  Updated patch attached.
>
> Looks good to me.

Thank you.  If it's okay, I'd like it if the two, now simple, patches 
could be merged now before the third one, as this third one will take 
some time.

> > > > > [ Oh ... how I hate that echo area code.  ]
> > > I have the impression that a whole lot of code can run between the
> > > `clear_message` and your code, so I don't immediately see why we can 
> > > be
> > > sure that `echo_area_buffer[1]` indeed always contains the thing 
> > > before
> > > the `clear_message`.  And if it doesn't, then maybe we shouldn't try 
> > > to
> > > revert the echo message.
> >
> > Good point. I will update my patch to have a copy of the echo area 
> > made
> > inside read_key_sequence.
>
> I don't see this in your patch, so I assume it'll be in a subsequent 
> patch.

Yup!

> > To delay until we're sure, we'd need to have some sort of
> > assumption of how terminal escape sequences are received that normal 
> > humans
> > would never do. Consider that the following key sequence is a mouse 
> > movement
> > escape sequence but is completely possible for a human to type slowly:
> >
> > ESC [ < 3 5 ; 1 9 ; 3 4 m
> >
> > What should the echo area display if it has read "ESC ["? At this 
> > point,
> > input-decode-map still doesn't know if this is a xterm escape sequence 
> > or
> > not.
>
> Right, so indeed the best we can do is to record the clear in such a 
> way
> that we can undo it as faithfully as possible.  This also begs the 
> question
> of what I mean by "*the* clear" since there's presumably going to be 
> one
> clear per byte in the above sequence.

I don't think remembering per input character is needed. Just one value 
is sufficient because the only case that needs to be handled is 
restoring the echo state when mock_input would be 0.

Consider what *should* happens when if, for example, the input is:

C-x 8 ESC [ < 3 5 ; 1 9 ; 3 4 m

The mouse movement escape sequence will be stripped, mock_input will be 
set to 2, and the code will goto replay_sequence.  At this point, one of 
two things should happen:

a) If this was done faster than `echo-keystrokes', the echo area should 
be empty as pressing a key clears the echo area.
b) If this was done slower than `echo-keystrokes', the echo area should 
display "C-x 8-" as waiting after pressing a key displays the keys typed 
in.

Both of the above will happen based on the existing logic of calling 
add_command_key() followed by echo_now() when mock_input is non-zero.  
The only case this does not handle is when mock_input is zero, hence 
that's the case to restore to.

  -- MJF