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: Wed, 18 Nov 2020 19:40:42 +0200 Message-ID: <83o8jupnqd.fsf@gnu.org> References: Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="30370"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Jared Finder Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Nov 18 18:44:56 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 1kfRVn-0007nQ-J1 for ged-emacs-devel@m.gmane-mx.org; Wed, 18 Nov 2020 18:44:55 +0100 Original-Received: from localhost ([::1]:33756 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kfRVm-0008It-Ib for ged-emacs-devel@m.gmane-mx.org; Wed, 18 Nov 2020 12:44:54 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:44614) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kfRRm-0005Od-Sx for emacs-devel@gnu.org; Wed, 18 Nov 2020 12:40:46 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:58041) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kfRRm-0004wz-AW; Wed, 18 Nov 2020 12:40:46 -0500 Original-Received: from [176.228.60.248] (port=1329 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1kfRRk-0008Tr-8o; Wed, 18 Nov 2020 12:40:46 -0500 In-Reply-To: (message from Jared Finder on Sun, 15 Nov 2020 22:29:20 -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:259367 Archived-At: > Date: Sun, 15 Nov 2020 22:29:20 -0800 > From: Jared Finder > Cc: emacs-devel@gnu.org > > >> 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. Soon. > > 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.) I don't think I follow. All the places where you need changes are related to handling mouse events, so why cannot it be specific to xt-mouse? > 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)))) Doesn't look too bad, but I don't think I have a clear idea of how you thought to use this in those places where you need xt-mouse to be supported? > 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 think I like this latter alternative better. It is slightly less elegant, but simpler and less risky. Can you show a draft of a patch along those lines? Thanks.