From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.bugs Subject: bug#29349: [Patch] Bug 29349: read_key_sequence is only partially recursive. This is a bug. Date: Mon, 20 Nov 2017 17:27:26 +0000 Message-ID: <20171120172726.GA3917@ACM> References: <20171118093843.GA3819@ACM> <20171119123456.GA4576@ACM> <20171119155908.GB4576@ACM> <83tvxqdwyy.fsf@gnu.org> <20171119174521.GB9922@ACM> <83mv3idu4w.fsf@gnu.org> <20171119204121.GE9922@ACM> <83ine5ei9j.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1511199074 11865 195.159.176.226 (20 Nov 2017 17:31:14 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 20 Nov 2017 17:31:14 +0000 (UTC) User-Agent: Mutt/1.7.2 (2016-11-26) Cc: 29349@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Nov 20 18:31:08 2017 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eGpuR-0002Qm-Qy for geb-bug-gnu-emacs@m.gmane.org; Mon, 20 Nov 2017 18:31:03 +0100 Original-Received: from localhost ([::1]:58561 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eGpuZ-0005SW-9b for geb-bug-gnu-emacs@m.gmane.org; Mon, 20 Nov 2017 12:31:11 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35226) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eGpuT-0005SC-DP for bug-gnu-emacs@gnu.org; Mon, 20 Nov 2017 12:31:06 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eGpuQ-0003p6-80 for bug-gnu-emacs@gnu.org; Mon, 20 Nov 2017 12:31:05 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:40596) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eGpuQ-0003p2-4V for bug-gnu-emacs@gnu.org; Mon, 20 Nov 2017 12:31:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1eGpuP-0002OX-PJ for bug-gnu-emacs@gnu.org; Mon, 20 Nov 2017 12:31:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 20 Nov 2017 17:31:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 29349 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 29349-submit@debbugs.gnu.org id=B29349.15111990439181 (code B ref 29349); Mon, 20 Nov 2017 17:31:01 +0000 Original-Received: (at 29349) by debbugs.gnu.org; 20 Nov 2017 17:30:43 +0000 Original-Received: from localhost ([127.0.0.1]:49277 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eGpu7-0002O1-5X for submit@debbugs.gnu.org; Mon, 20 Nov 2017 12:30:43 -0500 Original-Received: from ocolin.muc.de ([193.149.48.4]:57726 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1eGpu5-0002Ns-9N for 29349@debbugs.gnu.org; Mon, 20 Nov 2017 12:30:41 -0500 Original-Received: (qmail 16311 invoked by uid 3782); 20 Nov 2017 17:30:37 -0000 Original-Received: from acm.muc.de (p548C744B.dip0.t-ipconnect.de [84.140.116.75]) by colin.muc.de (tmda-ofmipd) with ESMTP; Mon, 20 Nov 2017 18:30:36 +0100 Original-Received: (qmail 3942 invoked by uid 1000); 20 Nov 2017 17:27:26 -0000 Content-Disposition: inline In-Reply-To: <83ine5ei9j.fsf@gnu.org> X-Delivery-Agent: TMDA/1.1.12 (Macallan) X-Primary-Address: acm@muc.de X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:140145 Archived-At: Hello, Eli. On Mon, Nov 20, 2017 at 05:33:28 +0200, Eli Zaretskii wrote: > > Date: Sun, 19 Nov 2017 20:41:21 +0000 > > Cc: 29349@debbugs.gnu.org > > From: Alan Mackenzie [ .... ] > > > .... and (b) why do we need the followup patch -- with the mouse-1 > > > events injected into the sequence the "translation" looks correct and > > > even educational. > > I don't think it looks correct. The C-down-mouse-3 which exists as an > > essential part of the key sequence has been overwritten in the > > "translation". > That's not what I see here, with your patch applied in keyboard.c, I > see this: > (translated from > ) at that spot runs the command > indent-pp-sexp (found in global-map), which is an interactive compiled > Lisp function in `lisp-mode.el'. > So C-down-mouse-3 is still there, we just have each click in the menus > injected into the sequence. What did you see after applying that > patch. Apologies. I wasn't paying enough attention to your post, and I was a little confused. > > The other thing is that if mouse-movements get into the raw event buffer > > (which I've seen, but for some reason amn't seeing any more) the > > "translated from" could become objectionably long. > I don't see that as a problem. OK. > > I think the "translated from" bit is intended to document a sequence the > > user is aware of (such as a double click) being translated into a > > different sequence she's aware of (such as a single click). > And that's exactly what happens in this case. > > The mouse-1, I believe, is more part of the user's subconsciousness > > rather than awareness. > But those mouse-1 clicks are real. OK, again. I think I would still prefer to suppress that "translated from" message, but it's not a strong preference, and not a terribly important point. So, I'll get on and commit my patch to keyboard.c (to master), but leave help.el alone. If those "translated from"s ever do get to be objectionable, as measured by user response, we can always do something about them later. -- Alan Mackenzie (Nuremberg, Germany).