From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Additional cleanup around xterm-mouse Date: Sun, 15 Nov 2020 20:11:33 +0200 Message-ID: <83eekutrqi.fsf@gnu.org> References: <55b9d194841a7c65a8ca52b1ea0d3293@finder.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="16057"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Jared Finder Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Nov 15 19:12:14 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 1keMVZ-00043n-PB for ged-emacs-devel@m.gmane-mx.org; Sun, 15 Nov 2020 19:12:13 +0100 Original-Received: from localhost ([::1]:32820 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1keMVY-0008BB-RX for ged-emacs-devel@m.gmane-mx.org; Sun, 15 Nov 2020 13:12:12 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:37236) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1keMV6-0007jR-12 for emacs-devel@gnu.org; Sun, 15 Nov 2020 13:11:44 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:46026) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1keMV5-0000DW-Ba; Sun, 15 Nov 2020 13:11:43 -0500 Original-Received: from [176.228.60.248] (port=1427 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1keMV4-0002sD-OX; Sun, 15 Nov 2020 13:11:43 -0500 In-Reply-To: <55b9d194841a7c65a8ca52b1ea0d3293@finder.org> (emacs-devel@gnu.org) 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:259201 Archived-At: > Date: Sun, 15 Nov 2020 00:49:03 -0800 > From: Jared Finder via "Emacs development discussions." > > The first patch is very straightforward and should be trivial to review > and merge. Agreed. > I have a question about the right way to proceed with the second patch. > Redirecting to read-key seems like the right solution here as it is > "read-event but also take input-decode-map into account". I needed to > make a change to read-key's implementation to make it also return button > down events and I saw two ways to do that. I would like advice on which > way is preferred. In the patch you can see the two options commented in > subr.el with Option 1 enabled by default. Ouch, this is scary. We have a lot of gray hair from replacing input functions by seemingly-similar other input functions. And on top of that, you need changes to read-key. These changes will affect every "native" mouse subsystem out there, with the benefit being a single niche mouse subsystem that is an emulator. This sounds like not the best way, as the risk will be shared by many important configurations and the benefits by only one not very important one. Can you think about a way of doing this that will affect only xterm-mouse? I'm okay with, for example, replacing read-event in those cases with some new function that will call a special xterm-mouse API when xterm-mouse is in effect, and will call read-event otherwise. Is something like this feasible? Thanks.