From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.bugs Subject: bug#29478: [SUSPECTED SPAM] Re: [Patch] bug#29478: 26.0.90; `C-h k' followed by mouse clicks no longer shows down event Date: Sun, 07 Jan 2018 13:03:19 -0500 Message-ID: References: <20171128221036.GC14868@ACM> <83o9ni3l3i.fsf@gnu.org> <83bmji2xye.fsf@gnu.org> <83tvwzubez.fsf@gnu.org> <20171222220549.GC8072@ACM> <833741lr0t.fsf@gnu.org> <20171223111726.GA6618@ACM> <20171223210407.GC6618@ACM> <831sjcfq1v.fsf@gnu.org> <83zi5q997a.fsf@gnu.org> <83efn18sv6.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1515348143 28577 195.159.176.226 (7 Jan 2018 18:02:23 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 7 Jan 2018 18:02:23 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: acm@muc.de, 29478@debbugs.gnu.org, npostavs@users.sourceforge.net To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Jan 07 19:02:19 2018 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 1eYFGq-0006Y3-HM for geb-bug-gnu-emacs@m.gmane.org; Sun, 07 Jan 2018 19:02:08 +0100 Original-Received: from localhost ([::1]:32866 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eYFIp-0005Fd-QO for geb-bug-gnu-emacs@m.gmane.org; Sun, 07 Jan 2018 13:04:11 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41529) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eYFIj-0005DZ-Bw for bug-gnu-emacs@gnu.org; Sun, 07 Jan 2018 13:04:06 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eYFIg-0000nu-6T for bug-gnu-emacs@gnu.org; Sun, 07 Jan 2018 13:04:05 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:59383) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eYFIg-0000nl-2N for bug-gnu-emacs@gnu.org; Sun, 07 Jan 2018 13:04:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1eYFIf-0003UQ-Ps for bug-gnu-emacs@gnu.org; Sun, 07 Jan 2018 13:04:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 07 Jan 2018 18:04:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 29478 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: confirmed Original-Received: via spool by 29478-submit@debbugs.gnu.org id=B29478.151534821613382 (code B ref 29478); Sun, 07 Jan 2018 18:04:01 +0000 Original-Received: (at 29478) by debbugs.gnu.org; 7 Jan 2018 18:03:36 +0000 Original-Received: from localhost ([127.0.0.1]:39831 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eYFID-0003Tk-SG for submit@debbugs.gnu.org; Sun, 07 Jan 2018 13:03:34 -0500 Original-Received: from pmta21.teksavvy.com ([76.10.157.36]:19720) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eYFIC-0003TX-Io for 29478@debbugs.gnu.org; Sun, 07 Jan 2018 13:03:32 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2EfHACZX1Ja/yyKSC1cHAEBAQQBAQoBAYM/gVqOQ45xggKZPwqFOwKEMkMUAQEBAQEBAQEBA2gohSUBBAF5BQsLDScHCxQYMS6KDgi0LCECig4BAQEBAQUBAQEBJIQgghWDP4MuixoFkzmQJYswTItZiXcoD4dElxeBPDYjgVAyGggwgiJGglMcGYFsI4pRAQEB X-IPAS-Result: A2EfHACZX1Ja/yyKSC1cHAEBAQQBAQoBAYM/gVqOQ45xggKZPwqFOwKEMkMUAQEBAQEBAQEBA2gohSUBBAF5BQsLDScHCxQYMS6KDgi0LCECig4BAQEBAQUBAQEBJIQgghWDP4MuixoFkzmQJYswTItZiXcoD4dElxeBPDYjgVAyGggwgiJGglMcGYFsI4pRAQEB X-IronPort-AV: E=Sophos;i="5.46,326,1511845200"; d="scan'208";a="17041347" Original-Received: from unknown (HELO ceviche.home) ([45.72.138.44]) by smtp.teksavvy.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Jan 2018 13:03:26 -0500 Original-Received: by ceviche.home (Postfix, from userid 20848) id D4ADC66326; Sun, 7 Jan 2018 13:03:19 -0500 (EST) In-Reply-To: <83efn18sv6.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 07 Jan 2018 19:46:05 +0200") 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:141881 Archived-At: > We don't show unbound sequences anywhere else, except if they are > explicitly asked about. Not sure why this case should be different. Try C-h c C-H-mouse-1 and it will dutifully report that C-H-mouse-1 is undefined. IOW, this is really not a new behavior in `C-h c`. >> I think it's also useful to show to the user than there were two events. > I don't think I agree. Moreover, when dragging there are more than 2 > events, but we only show 2. Indeed, there's a whole bunch of options in terms of how much detail we may want to show. >> > Also, if both events are bound, I think we should show the mouse-N >> > event before the down-mouse-N event, because the former is much more >> > important and normally is the one that's bound. >> >> If the down event is unbound it's not shown (this is actually not >> a feature I actively tried to obtained: it's just the result of >> read-key-sequence dropping the down event if it's not bound). > That's an inconsistency I don't think I like. Neither do I. But it would require a fairly nasty hack to try and make it behave differently, and given all the key remapping we do, there will always be such inconsistencies, I think. OTOH, for text-terminals, we add a "(translated from )" and we could do the same here (that's what my patch originally did, by the way, and that's what I've been using all these years since I think it's very valuable information), which would say: (translated from ) at that spot is undefined thus exposing the fact that there was also a event that got dropped along the way. >> And I think it's important to preserve the order of the events. > The order reversed is still an order ;-) I guess if we reverse them all (i.e. always show events last-to-first), I could live with it. >> As a side-benefit it reduces the amount of ad-hoc code that needs to >> know about what is a down event or a mouse event and so on. > Yes, correct solutions frequently need more messy code ;-) In my experience it too often leads to code which is "more correct" in 90% of the cases but inconsistent in the rest. Stefan