From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Jared Finder via "Emacs development discussions." Newsgroups: gmane.emacs.devel Subject: Re: Additional xterm-mouse cleanup Date: Wed, 24 Feb 2021 22:08:21 -0800 Message-ID: References: <4ab742d461a50a1b9a0debba781a18ad@finder.org> <3e616ab0b40a4141c8688e9cdc95cdfc@finder.org> Reply-To: Jared Finder Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="39075"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Roundcube Webmail/1.3.16 Cc: "jared--- via \"Emacs development discussions.\"" To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Feb 25 07:09:20 2021 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lF9pw-000A3N-DT for ged-emacs-devel@m.gmane-mx.org; Thu, 25 Feb 2021 07:09:20 +0100 Original-Received: from localhost ([::1]:53276 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lF9pv-0007aQ-Fa for ged-emacs-devel@m.gmane-mx.org; Thu, 25 Feb 2021 01:09:19 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:35274) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lF9p6-00079S-9X for emacs-devel@gnu.org; Thu, 25 Feb 2021 01:08:28 -0500 Original-Received: from greenhill.hpalace.com ([2600:3c01::f03c:91ff:fe73:2daa]:51220) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lF9p4-0003J0-9F for emacs-devel@gnu.org; Thu, 25 Feb 2021 01:08:27 -0500 Original-Received: from mail.finder.org (greenhill.hpalace.com [IPv6:2600:3c01::f03c:91ff:fe73:2daa]) by greenhill.hpalace.com (Postfix) with ESMTPSA id 6C6D5DF; Thu, 25 Feb 2021 06:08:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=finder.org; s=2018; t=1614233302; bh=nMzgbatsE2qQFLQEbOyg+5tF86eifxlxBchHjiJLNEw=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=xYy/sjpXQlNcMFPYJ+YCmmRUsPB1t4aEVra4D60uhy65Jc4qUq/i9v9IzPC5j6bKp ue3C1oTWmOzGT3LXXChKePegtgVi/54Up6PK88AC5DHqhwy0S1FbjQkUsRY0qDN1r3 xn+sOxzTBie5m1OT6EJJENLfpDHM+SDdn+K/G3I7zLSDhzOYTN0IxX5yxKfYJLX0Gb IQrm4a/KSVHYjoqA9V4m8JspNFJoytnIFowg/UzYU0Gu7XTkRSoTsAkTWrO123/Qqp tX6zO5R4RhXE/B2ipLr2TUg32nDh46KBUVvPHFJv+wSH91vdPWPZp7MT5TTFy5AeId PeTk356S24pGA== In-Reply-To: X-Sender: jared@finder.org Received-SPF: pass client-ip=2600:3c01::f03c:91ff:fe73:2daa; envelope-from=jared@finder.org; helo=greenhill.hpalace.com X-Spam_score_int: 12 X-Spam_score: 1.2 X-Spam_bar: + X-Spam_report: (1.2 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_SBL_CSS=3.335, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:265607 Archived-At: 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