|
From: | Jared Finder |
Subject: | Re: Additional xterm-mouse cleanup |
Date: | Wed, 24 Feb 2021 22:08:21 -0800 |
User-agent: | Roundcube Webmail/1.3.16 |
On 2021-02-24 7:56 pm, Stefan Monnier wrote:
Ah, got it. I agree, it is mostly straightforward. To do this properlyrequired making an assumption that .timestamp=0 for SELECT_WINDOW_EVENT isok. 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 torevert the echo message.Good point. I will update my patch to have a copy of the echo area madeinside 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 ofassumption of how terminal escape sequences are received that normal humans would never do. Consider that the following key sequence is a mouse movementescape sequence but is completely possible for a human to type slowly: ESC [ < 3 5 ; 1 9 ; 3 4 mWhat 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 ornot.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 oneclear 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 mThe 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
[Prev in Thread] | Current Thread | [Next in Thread] |