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: Wed, 23 Dec 2020 09:21:10 -0800 Message-ID: <9668a5ae6418bad910d833c95b8d04b9@finder.org> 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> <83bleptzng.fsf@gnu.org> <831dc4a610325c009c5a10c48fe459e5@finder.org> <858d85fc265455042479cb4c9a72b4a5@finder.org> <83lfdopiqy.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="12664"; 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 23 18:21:52 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 1ks7pf-0003Bh-E7 for ged-emacs-devel@m.gmane-mx.org; Wed, 23 Dec 2020 18:21:51 +0100 Original-Received: from localhost ([::1]:45182 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ks7pe-00047J-F0 for ged-emacs-devel@m.gmane-mx.org; Wed, 23 Dec 2020 12:21:50 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:47310) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ks7p7-0003W4-57 for emacs-devel@gnu.org; Wed, 23 Dec 2020 12:21:17 -0500 Original-Received: from greenhill.hpalace.com ([2600:3c01::f03c:91ff:fe73:2daa]:53216) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ks7p5-0001LV-7q; Wed, 23 Dec 2020 12:21:16 -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 D719E7EC; Wed, 23 Dec 2020 17:21:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=finder.org; s=2018; t=1608744070; bh=kTGX/4A51X9yWOvBeQT2WLR+3BLDWw9pn0FYCRVqxAo=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=02KNapiHuuifsShHndSNGQ9bdY7lTfStj1fySJQ3ZObGD2/45LGCn9wzx7mRdJgt1 Qvh+TxszdYyjyw9hUzLwl129zzFFeZ0hWqBDbdCYHQmkOFFN5iP1uxT6fTjWRu+sHp m4etF2MNiJJ0j4dj//jdjdwLTq6Jme8VJEAWrqo3ja1zer5cSk94sxXGwLp70UlX4M +WHqhk+7gj2kkSRfZ/MofEDA8meLP9LOobH+wnp11/60dRLYpqEvrEFx/XoxzUDxrl MOCvnH4OV3X1hVK+vPIMiLrBfyMvd9TjP/u9SCbQqhvN2Ue5vioVzsvdtiI5hfmyi9 LHpflobur2MwA== In-Reply-To: <83lfdopiqy.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:261623 Archived-At: On 2020-12-23 8:52 am, Eli Zaretskii wrote: >> Date: Sun, 20 Dec 2020 15:27:10 -0800 >> From: Jared Finder >> Cc: Eli Zaretskii , emacs-devel@gnu.org >> >> >> I like #3 as existing code would run unchanged. The chance that any >> >> existing code passed 'all-fallbacks is extremely low. And anyone >> >> supporting >> >> a package outside of Emacs passing some other value will notice the >> >> message >> >> when they upgrade to Emacs 28. >> >> >> >> Thoughts? >> > >> > By order of preference, I'd say: #1, then #3 and finally #2. >> > But any one of those 3 is OK for me. >> >> Sounds good to me! Eli, do you have a preference here? I'd like to >> make >> sure I implement the right option. > > I'm afraid I've lost context here. Your suggestion was to use this: > >> +(defun read-potential-mouse-event () >> + "Read an event that might be a mouse event. >> + >> +This function exists for backward compatibility in code packaged >> +with Emacs. Do not call it directly in your own packages." >> + (if xterm-mouse-mode >> + (read-key nil t) >> + (read-event))) > > This uses read-key when xterm-mouse-mode is in use, otherwise uses > read-event as we did before. > > But now the discussion is about read-key only, and also about > read-key-sequence, which was not on the table at all, AFAIR? There > seems to be some gap here that I couldn't bridge upon. The additional thing to keep in mind is that read-key is implemented on top of read-key-sequence. read-key currently will never return down mouse events due to them being discarded in the (C function) read_key_sequence. I highlighted a way to do this in the original patch in this email thread. Stefan requested an alternative, which is to extend the behavior of the dont-downcase-last parameter to read-key-sequence. As this changes behavior for read-key-sequence, I want to know what is the right way to make this behavior change. To simplify things, I think we can only look at #1 and #3, as both Stefan and I agree #3 is better than #2. The three choices I presented were: 1. [Stefan's preference] Change the behavior of the dont-downcase-last parameter to this more extensive meaning. Update global-set-key (the only other caller who sets dont-downcase-last in Emacs' code) to take this new behavior into account. 2. Make the dont-downcase-last parameter have the new behavior only if it is passed some new value (for example: 'all-fallbacks). Leave the existing behavior for any other value, especially 'nil and 't. 3. [My preference] Like 2, but with a deprecation message on values other than 'nil, 'all-fallbacks, or 't (or maybe 'downcase-last if we want full explicitness). This allows maximal ability to define new behaviors in the future. > So I'm sorry for slowing you down, but could you explain how the 3 > possibilities you describe are related to the original issue, which > was that read-event is insufficient to support xterm-mouse-mode in > those places? No need to apologize. I realize read_key_sequnce is the *CORE* part of Emacs' input handling so any change needs to be handled with utmost care. -- MJF