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: Sat, 28 Nov 2020 18:36:34 +0200 Message-ID: <83mtz1moa5.fsf@gnu.org> References: <83o8jupnqd.fsf@gnu.org> <838savys2v.fsf@gnu.org> <3e3933d8ec1d5d3f6809385a8ac5f447@finder.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="1749"; 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 Sat Nov 28 17:37:47 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 1kj3EJ-0000OL-Q7 for ged-emacs-devel@m.gmane-mx.org; Sat, 28 Nov 2020 17:37:47 +0100 Original-Received: from localhost ([::1]:50432 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kj3EI-0008Q4-OA for ged-emacs-devel@m.gmane-mx.org; Sat, 28 Nov 2020 11:37:46 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:33488) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kj3DO-0007Vx-DN for emacs-devel@gnu.org; Sat, 28 Nov 2020 11:36:50 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:46402) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kj3DN-0006Ba-Gd; Sat, 28 Nov 2020 11:36:49 -0500 Original-Received: from [176.228.60.248] (port=2344 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1kj3DM-0002Np-NZ; Sat, 28 Nov 2020 11:36:49 -0500 In-Reply-To: <3e3933d8ec1d5d3f6809385a8ac5f447@finder.org> (message from Jared Finder on Sun, 22 Nov 2020 15:56:50 -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:259957 Archived-At: > Date: Sun, 22 Nov 2020 15:56:50 -0800 > From: Jared Finder > Cc: emacs-devel@gnu.org > > > So I'm still asking why can't we do something like > > > > (if xterm-mouse-mode > > (read-key) > > (read-event)) > > > > in all the affected places that currently call read-event? > > This can be done in all places except widget-key-sequence-read-event > (see below for an explanation). Though it feels like a bad solution as > the info pages clearly state right now that if you want to read > translated events, you should use read-key, not read-event. Mouse > events always could be translated because of xterm-mouse-mode, so isn't > this just a bug? Maybe it is a bug, but somehow we've lived with it for a very long time. Btw, my main worry is not that we will begin to use translated events where we formerly didn't, it's that we will use an input function whose code is very different, and thus some aspects of its behavior in various situations could very well be subtly different, thus breaking some use cases. Try to compare the two functions and figure out whether they behave the same or not, and in what cases. The code is so different that even understanding how they both receive the same events is non-trivial. How does one assess risk from this change in cases like this one? > By the way, the info text I'm referring to is the following excerpt from > (elisp)Top > Command Loop > Reading Input > Reading One Event. > > We emphasize that, unlike ‘read-key-sequence’, the functions > ‘read-event’, ‘read-char’, and ‘read-char-exclusive’ do not perform the > translations described in Translation Keymaps. If you wish to > read a single key taking these translations into account, use the > function ‘read-key’: That's okay. We frequently tell "do as I say, not as I do", and there's nothing wrong with that: the ELisp manual is primarily a text for Lisp programmers, not a faithful description of the Emacs design and implementation (although it does include some of the latter). > Note: the wid-edit.el change is also pretty major and where I first > noticed this. Without some fix there, interaction with widgets in > Customize buffers with an xterm mouse will cause infinite loops that > only C-g can escape. I'm okay with making such a change in wid-edit.el, mainly because that case is unlikely to hit the problems I worry about, and even if it does, it's just one package. > Note that because function keys are also affected, for this function the > check whether to use read-key or read-event would need to be something > like: > > (if (eq window-system nil) ; This is correct on Linux and macOS, not > sure > ; if accurate for other platforms > (read-key) > (read-event)) That won't be necessary: in wid-edit.el, just replace read-event with read-key, and let's see how much this breaks. Thanks.