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: Tue, 15 Dec 2020 21:30:24 -0800 Message-ID: References: <83o8jupnqd.fsf@gnu.org> <838savys2v.fsf@gnu.org> <3e3933d8ec1d5d3f6809385a8ac5f447@finder.org> <83mtz1moa5.fsf@gnu.org> <0ea60a4f2a7fb0698f84ac5957cafef3@finder.org> <83mtyxgzck.fsf@gnu.org> <2eac7957a7c20af3517a3ad0862a5b39@finder.org> <106c6d31ef09b83042ef0fab5ac0ed88@finder.org> <505d1b561cde375d1c6a55a738cd553d@finder.org> <83ft48csj5.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="14299"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Roundcube Webmail/1.3.15 Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Dec 16 06:32:08 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 1kpPPz-0003dG-HP for ged-emacs-devel@m.gmane-mx.org; Wed, 16 Dec 2020 06:32:07 +0100 Original-Received: from localhost ([::1]:37828 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kpPPx-0001Yx-Fg for ged-emacs-devel@m.gmane-mx.org; Wed, 16 Dec 2020 00:32:05 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:44398) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kpPOQ-0000yK-Vd for emacs-devel@gnu.org; Wed, 16 Dec 2020 00:30:31 -0500 Original-Received: from greenhill.hpalace.com ([2600:3c01::f03c:91ff:fe73:2daa]:41072) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kpPOO-00029t-W4; Wed, 16 Dec 2020 00:30:30 -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 AEED05BB; Wed, 16 Dec 2020 05:30:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=finder.org; s=2018; t=1608096624; bh=/XvTGgGIongBYXMSMDxpTZdc5egVJBRc2y69QVTxMxA=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=oig4PyW79opi9ldn/+8EGbVaUWgOzd30YCz/WwlRuws/7sz0rQhIuDEpzT0zVpXM9 lwIADXloCSpQlMQ9Cf63NIMJVFTbXam8esVXt5vyNY8I4CuxTXR8NkzCm38SMDgYvO ARrBvPlOaI14WLZeNXkwslyiaijsIlbM2zdvNFQRshOr4NyIRmDdlfaeYsThYNJGau qu+KtZJWd1/V6RDiEfdnF5j4Q8nykXIQ43eRSG1ca2RGMtDh3UxDyXHtjiO1Ab2bYB CA93pZXvZjmDHjJYDj3WAVKn+RSfkqaolGfb2l7lr9ktgiHpZyMrSfBgHNPXF+ynpw jlKmjGZoPoQWA== In-Reply-To: <83ft48csj5.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:260948 Archived-At: On 2020-12-14 7:32 am, Eli Zaretskii wrote: >> Date: Sun, 13 Dec 2020 16:54:26 -0800 >> From: Jared Finder >> Cc: "Jared Finder via \"Emacs development discussions.\"" >> , Eli Zaretskii >> >> Any updates here? >> >> I do not know what the etiquette is here in terms of replies, so I'd >> like to apologize in advance if I'm just being impatient. > > FWIW, I was waiting for Stefan to react to your responses. It seems Stefan is very busy right now. Would you be okay deferring the issues Stefan raised? Or would you prefer to just wait? My impression is that his concern is around if it makes sense to add a new parameter to read-key and if inhibit--unbound-mouse-fallback should instead be done through function-key-map (avoiding adding a new var). But these can both be avoided: 1. I can just not add a new parameter to read-key. I only did this so that external packages had a solution that didn't involve inhibit--unbound-mouse-fallback or read-potential-mouse-event. 2. Since inhibit--unbound-mouse-fallback is internal (both in doc comment and in its name), it can safely be removed in the future. With the above done, if you / Stefan want to instead make this work via function-key-map and not add a parameter to read-key, that can be done while safely removing inhibit--unbound-mouse-fallback. Thoughts? I'm okay either way. -- MJF