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: Mon, 16 Nov 2020 09:30:41 -0800 Message-ID: References: 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="23043"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Roundcube Webmail/1.3.15 Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Nov 16 18:34:36 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 1keiOh-0005tS-FQ for ged-emacs-devel@m.gmane-mx.org; Mon, 16 Nov 2020 18:34:35 +0100 Original-Received: from localhost ([::1]:57132 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1keiOg-0007GS-IQ for ged-emacs-devel@m.gmane-mx.org; Mon, 16 Nov 2020 12:34:34 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:51214) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1keiL4-0004cp-Ps for emacs-devel@gnu.org; Mon, 16 Nov 2020 12:30:50 -0500 Original-Received: from greenhill.hpalace.com ([192.155.80.58]:52920) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1keiL2-0002TN-LY; Mon, 16 Nov 2020 12:30:50 -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 98436812; Mon, 16 Nov 2020 17:30:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=finder.org; s=2018; t=1605547842; bh=BdJl2aHpnRsk52V2dMRkeoAba3arhufKz7kDbB+bz/w=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=TATJ7AwfspEK2RxfZL5SxbwtdZBVYWwXy7YntNSw4R0hfRyT47c8Y7oPfjB+ch+4Y Lw1uG9i8MGxgvSZ7LY0GOmqhjq+jyK2j5wwC++2aeGGoJjzssROgIbimtZgufA+WGS Hd2r76l5ST7eiDWURArmouvtgdhQh92lQGx1zoFkGJEGaCmt39Roq/N0g+oF8DdiMS Tl9kGfU04txBTi1ruqIh/Ljz5PRgszX5iYkTaCNI9mdj2hHYoCVkF2eu/7Akm8oF3a tgMHB65z50XnMW5UJJTAvGVZdLyH2AE/D0zf9DyCLI7+g2omLwzadtQlJCLZ2aJL0h /uqfRgNyGpm6Q== 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-detected-operating-system: by eggs.gnu.org: First seen = 2020/11/16 12:30:43 X-ACL-Warn: Detected OS = Linux 2.2.x-3.x [generic] [fuzzy] 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:259240 Archived-At: On 2020-11-15 10:29 pm, Jared Finder wrote: > On 2020-11-15 10:11 am, Eli Zaretskii wrote: >>> 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. > > Great. It's completely independent of the other change, feel free to > merge at any time. > >>> I have a question about the right way to proceed with the second >>> patch. >>> [...] >> >> 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? > > I was a little nervous about changing read-key's default behavior too. > Happy to explore other options. :) > > Creating such an alternative function doesn't appear too bad if you're > okay with having the same run-with-idle-timer pattern that read-key > uses. I do not think it can be xterm specific as it needs to apply > all of input-decode-map to be able to return function keys such as > [f1] on a native Linux term or an xterm. (This is important for > widget-key-sequence-read-event.) However, it can avoid the rest of > the complexity of read-key-sequence. I'm imagining something like > this (untested code follows, just wanted to give a flavor of it): > > (defun read-decoded-key () ; I'd love a better name here. > ;; Start of code like read-key's code. > (let ((keys '()) > (timer (run-with-idle-timer > read-key-delay t > (lambda () > (unless (null keys) > (throw 'read-key nil)))))) > (unwind-protect > (while t (push (read-event) keys)) > (cancel-timer timer)) > > ;; Start of new stuff: Apply transformations from input-decode-map. > (do-stuff) > > (vconcat (nreverse keys)))) > > As you can see, this avoids all the complexity around managing the > different keymaps that read-key currently has since it calls > read-key-sequence. > > > An alternative is to just use read-key as is in most cases and make my > change a parameter / special variable. Most of my patch's changes > work fine with the existing behavior of read-key. Only the following > changes do not: > > * lisp/vc/ediff-wind.el (ediff-get-window-by-clicking) > ==> As coded, expects the first mouse event returned by read-event to > be a down-mouse-X event, which it then follows by another call to > read-event to get the mouse-X event. It could be easily changed to > only look for the up event. > > * lisp/strokes.el (strokes-read-stroke, strokes-read-complex-stroke) > * lisp/textmodes/artist.el (artist-mode-draw-poly) > ==> These both expect to detect a mix of down-mouse-X and mouse-X > events. > > * lisp/wid-edit.el (widget-key-sequence-read-event) > ==> This w/o changes to read-key, but with a behavior change. With no > changes to read-key it returns just a single up event. Currently on > other environments you get both a down and up event (e.g. > ). I meant to say here "This **works** w/o changes to read key, but with a behavior change." Sorry for any confusion caused. -- MJF