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, 02 Dec 2020 21:46:53 -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> 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="1446"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Roundcube Webmail/1.3.15 Cc: "Jared Finder via \"Emacs development discussions.\"" , Eli Zaretskii To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Dec 03 06:48:13 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 1kkhTR-0000GP-4R for ged-emacs-devel@m.gmane-mx.org; Thu, 03 Dec 2020 06:48:13 +0100 Original-Received: from localhost ([::1]:45458 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kkhTQ-0003tC-32 for ged-emacs-devel@m.gmane-mx.org; Thu, 03 Dec 2020 00:48:12 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:35276) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kkhSM-0003RI-BD for emacs-devel@gnu.org; Thu, 03 Dec 2020 00:47:06 -0500 Original-Received: from greenhill.hpalace.com ([192.155.80.58]:39682) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kkhSC-0004Zr-FW; Thu, 03 Dec 2020 00:47:05 -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 2F147605; Thu, 3 Dec 2020 05:46:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=finder.org; s=2018; t=1606974414; bh=SKH0qrPmsZ3+sCuwUhsca0DRWfz/ynHpsbSHL+keJ68=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=TlD7XqT5JxcRp7Jvb1zk5M0VtvrIeyREt5lXANmm9zJib1eisMQgytwY/Dqxj2aah feiv9K4r0Nm1KKYkJmdtzxUiFDP7KNRR2yTXX2skWycqUAQ8uWIIJB8liRWPmRmZ8r lN9BUZ9KYmsDx5SJJTqo6AcdyTAkE/xVbS/a3I5/GElN9lc4bI5YMwfszuNZ1zjuQe r3hVg2Y196AWCVMPfKH2/G4Q+i9qr+NIq1KFuoMHIYCumEZoP+8aDj/j3bvh+BTMJX /tmmJAsA0maauxh9a2QxK50MqUEz6RlXeorlIyVRHFQQrFWrt3ih3Y4LTsjGIY9rZl Pz8768WBivMRQ== In-Reply-To: X-Sender: jared@finder.org Received-SPF: pass client-ip=192.155.80.58; 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:260199 Archived-At: On 2020-12-02 8:53 am, Stefan Monnier wrote: >> Subject: [PATCH] Make libraries work with xterm-mouse-mode. > > Could you explain (at least in the code, and ideally here as well) why > we need this new `all-mouse-events` behavior? I updated the function locally to look like as follows. Let me know if you have further questions. (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." ;; `xterm-mouse-mode' events must go through `read-key' as they ;; are decoded via `input-decode-map'. (if xterm-mouse-mode (read-key nil ;; Normally `read-key' discards all mouse button ;; down events. However, we want them here. t) (read-event))) > `function-key-map` has very similar effects (and to a large extent, the > downgrading of mouse-down events controlled by `all-mouse-events` could > (I'd even say should) be implemented in `function-key-map` rather than > via the current ad-hoc code in read-key-sequence), so I'm not very > comfortable with treating these mouse-event-rewritings differently from > other rewritings. Just a few comments: Wouldn't that require binding 2^6 * 3 * 3 * 5 = 2880 events in function-key-map? (2^6 for six modifier keys, 3 for down vs up vs drag, 3 for single vs double vs triple, 5 for the mouse buttons). Is that an okay overhead to add on every key press? If not, it could instead be done with a default binding in function-key-map. In both of the above cases, I believe the mapping would need to be a Lisp function so it can conditionally decay a triple down event to a double, single, or nothing depending on what is bound. And such behavior would want a special variable (as the code is currently in my patch) to disable it to avoid copying all of function-key-map in read-key. So I think it is fully independent of my current patch. > The other question is why you made `all-mouse-events` an argument to > `read-key` but not to `read-key-sequence` (where you pass the info via > a dynamically-scoped var instead)? I did this to create an API for read-key but not for read-key-sequence. Any package that wants to read down mouse events and work with xterm-mouse should call (read-key nil t). I didn't want to create a way to do the same think for read-key-sequence at I could not think of a use case. The special variable is named inhibit--unbound-mouse-fallback to indicate it is private and could change or be removed in the future. -- MJF