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 cleanup around xterm-mouse Date: Mon, 30 Nov 2020 23:36:23 -0800 Message-ID: <0ea60a4f2a7fb0698f84ac5957cafef3@finder.org> References: <83o8jupnqd.fsf@gnu.org> <838savys2v.fsf@gnu.org> <3e3933d8ec1d5d3f6809385a8ac5f447@finder.org> <83mtz1moa5.fsf@gnu.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="17912"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Roundcube Webmail/1.3.15 Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Dec 01 08:37:12 2020 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 1kk0Do-0004ZN-Bt for ged-emacs-devel@m.gmane-mx.org; Tue, 01 Dec 2020 08:37:12 +0100 Original-Received: from localhost ([::1]:38930 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kk0Dn-0008OV-E7 for ged-emacs-devel@m.gmane-mx.org; Tue, 01 Dec 2020 02:37:11 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:57756) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kk0D6-0007xk-VK for emacs-devel@gnu.org; Tue, 01 Dec 2020 02:36:28 -0500 Original-Received: from greenhill.hpalace.com ([2600:3c01::f03c:91ff:fe73:2daa]:52580) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kk0D5-0000Ch-1Q; Tue, 01 Dec 2020 02:36:28 -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 DA451605; Tue, 1 Dec 2020 07:36:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=finder.org; s=2018; t=1606808183; bh=pqFQH7WE/TtstfdRK+qB8/WFkJTmL1thwz+D8Kg0tbA=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=OAXtbkZcyOb/nbR/KbqaP1p/O8g/zkTuePuGw0U7JCmDcaWbrTPPypKdBYN4dztgK jfIu1KZpHZUBJGXqKP1CoMaF7wF1DiV6f8sY0HW3+qDqCHUPudVtEb/4sQ5OUUFVp0 JDbv+QzfszOqi8KKlvFabegEcpzNfUm6Df/emR53HSoEDtimaF/gFmrTF5Gxlkv6sh rONhDpJzwpYBSvNOSMmXYmgQBVQRzmqZrO9MnzHSO5YgjmnL8BCP8M7pAyb8m54US6 YwuUp5H8V3Vii8+L7KYqiUTwGAOn5ByBAohgm5ZBXT3eLX6AnOBjOX8oKj2+b87AyT 38PS6x3GZ0pUA== In-Reply-To: <83mtz1moa5.fsf@gnu.org> 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:260107 Archived-At: On 2020-11-28 8:36 am, Eli Zaretskii wrote: >> Date: Sun, 22 Nov 2020 15:56:50 -0800 >> From: Jared Finder >> Cc: emacs-devel@gnu.org >> >> > So I'm still asking why can't we do something like >> > >> > (if xterm-mouse-mode >> > (read-key) >> > (read-event)) >> > >> > in all the affected places that currently call read-event? >> >> This can be done in all places except widget-key-sequence-read-event >> (see below for an explanation). Though it feels like a bad solution >> as >> the info pages clearly state right now that if you want to read >> translated events, you should use read-key, not read-event. Mouse >> events always could be translated because of xterm-mouse-mode, so >> isn't >> this just a bug? > > Maybe it is a bug, but somehow we've lived with it for a very long > time. > > Btw, my main worry is not that we will begin to use translated events > where we formerly didn't, it's that we will use an input function > whose code is very different, and thus some aspects of its behavior in > various situations could very well be subtly different, thus breaking > some use cases. Try to compare the two functions and figure out > whether they behave the same or not, and in what cases. The code is > so different that even understanding how they both receive the same > events is non-trivial. How does one assess risk from this change in > cases like this one? This makes sense to me. I agree that read-key is likely to currently behave different in some situations from read-event. Are these differences bugs that should be fixed or are they now features that can not be changed? I ask because I feel bad about adding yet another difference between xterm-mouse and "native" mouse support. I'm about 33% through analyzing read-key and have already found the following differences: * read-key resets this-command-keys, read-event appends to it. * read-key does not return switch-frame events as they happen, read-event does. Are these bugs to fix? If so perhaps an exhaustive analysis with good unit test coverage could address the risk here and provide a path to removing such a difference in the future. I agree that in the short term, adding (if xterm-mouse-mode (read-key) (read-event)) is the safest path. >> Note that because function keys are also affected, for this function >> the >> check whether to use read-key or read-event would need to be something >> like: >> >> (if (eq window-system nil) ; This is correct on Linux and macOS, not >> sure >> ; if accurate for other platforms >> (read-key) >> (read-event)) > > That won't be necessary: in wid-edit.el, just replace read-event with > read-key, and let's see how much this breaks. Sounds good. I will modify my patch soon. -- MJF