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: Thu, 24 Dec 2020 20:43:24 +0200 Message-ID: <83o8ijniyb.fsf@gnu.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> <9668a5ae6418bad910d833c95b8d04b9@finder.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="30437"; mail-complaints-to="usenet@ciao.gmane.io" Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Jared Finder Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Dec 24 19:44:32 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 1ksVbE-0007p6-LU for ged-emacs-devel@m.gmane-mx.org; Thu, 24 Dec 2020 19:44:32 +0100 Original-Received: from localhost ([::1]:42358 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ksVbD-000862-Nf for ged-emacs-devel@m.gmane-mx.org; Thu, 24 Dec 2020 13:44:31 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:57858) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ksVaU-0007fr-3e for emacs-devel@gnu.org; Thu, 24 Dec 2020 13:43:46 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:45162) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ksVaT-0000mp-4Q; Thu, 24 Dec 2020 13:43:45 -0500 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:3527 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1ksVaS-00049F-K8; Thu, 24 Dec 2020 13:43:44 -0500 In-Reply-To: <9668a5ae6418bad910d833c95b8d04b9@finder.org> (message from Jared Finder on Wed, 23 Dec 2020 09:21:10 -0800) 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:261702 Archived-At: > Date: Wed, 23 Dec 2020 09:21:10 -0800 > From: Jared Finder > Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org > > >> +(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. And xterm-mouse-mode does need these down-mouse events? For what purpose? > 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. I prefer 3 or 2. 1 sounds too radical to me. It's true that in core there's only one caller, but we have no idea what happens outside of the core.