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: Sun, 22 Nov 2020 15:56:50 -0800 Message-ID: <3e3933d8ec1d5d3f6809385a8ac5f447@finder.org> References: <83o8jupnqd.fsf@gnu.org> <838savys2v.fsf@gnu.org> Reply-To: Jared Finder Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="35088"; 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 23 00:57:53 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 1kgzEv-00091F-3J for ged-emacs-devel@m.gmane-mx.org; Mon, 23 Nov 2020 00:57:53 +0100 Original-Received: from localhost ([::1]:43620 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kgzEu-0003GJ-55 for ged-emacs-devel@m.gmane-mx.org; Sun, 22 Nov 2020 18:57:52 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:47654) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kgzE0-0002n5-AT for emacs-devel@gnu.org; Sun, 22 Nov 2020 18:56:56 -0500 Original-Received: from greenhill.hpalace.com ([192.155.80.58]:59342) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kgzDy-0005Wy-Ed; Sun, 22 Nov 2020 18:56:56 -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 6B60664B; Sun, 22 Nov 2020 23:56:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=finder.org; s=2018; t=1606089410; bh=8E7k1Nto042GIgp+G/9K/YHC3YaHGt8TP5Ihg1U0kPQ=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=Slz3lgr3usGlv0nLCJv1+s+Z/wi+9sRJgXUqBoefEruqxPV1JiUkQUxv+FU20O54Y 945fsTrB6Qn7EaXAGdeSIIpoHKLpVAGPZHOcMBKL656ps8rrTfEnQDYP3x/PqMBhHP g+a3auhu+6Ya2mbHXhULEChQYp7OlcsXq1MQIclOfoKQngWuRzZAJlBDnDVM+EF1ll UJd1BfUgEIJS2YZO2UQKolFC8ijaAAc4ceRNnIqery/ZcB0OQtMO3UGlvF9M0hbpJX 8A3iLRNBL3lkTKIJU0ix7RskzyqXIOkKKtiztUH1spyayRtZhrBtvMxLQOEJv8MdZH HywfRsetS4Kpw== In-Reply-To: <838savys2v.fsf@gnu.org> 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:259657 Archived-At: On 2020-11-21 1:31 am, Eli Zaretskii wrote: >> Date: Thu, 19 Nov 2020 00:03:30 -0800 >> From: Jared Finder >> Cc: emacs-devel@gnu.org >> >> > 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? >> >> There is a bug in widget-key-sequence-read-event's usage of keyboard >> events specifically. >> >> The function widget-key-sequence-read-event currently does not >> correctly >> translate function keys for the terminal. It has code that attempts >> to >> apply function-key-map, but does not apply input-decode-map, so it can >> not read function keys. (Additionally, it should be using >> local-function-key-map now.) > > OK, but that means widget-key-sequence-read-event has a bug that needs > to be fixed regardless. > > 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? I completely agree with the goal to make sure to preserve backward compatibility issues, but I think a better approach would be to add the additional functionality to read-key to make it a safe replacement for read-event. (This seems aligned with how I read Stefan's recent comment on this thread as well.) 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’: > So I'm still wary of making such a > significant change, even though we are talking about a small number of > relatively minor feature (with the sole exception of Ediff, perhaps). 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. >> (let ((ev2 (and (memq 'down (event-modifiers ev)) >> - (read-event))) >> - (tr (and (keymapp function-key-map) >> - (lookup-key function-key-map (vector ev))))) >> + (read-key))) >> + ;; This is actually a separate bug-fix. `function-key-map' >> + ;; does not contain any term-specific function key mappings >> + ;; like f13 --> S-f1. >> + (tr (and (keymapp local-function-key-map) >> + (lookup-key local-function-key-map (vector ev))))) > > Let's fix this part separately. The underlying issue with function keys is the same as the xterm-mouse issue (failure to apply input-decode-map), so the solutions may be intertwined. Terminal function keys and xterm mouse events both get decoded through input-decode-map. 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)) Without the change from read-event to read-key throughout this function, 'ev' will never contain an event that would be translated by local-function-key-map or function-key-map from what I've seen. It may be a better path to convert this function to just call (read-key "Prompt" t) like the rest of the modifications. If this is done, then local-function-key-map is already applied. I realize that is a behavior change, but given how fragile reconstructing the way translation maps already is, I think it is worth considering. -- MJF