From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii 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 19:46:05 +0200 Message-ID: <83efn18sv6.fsf@gnu.org> 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> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1515347119 9554 195.159.176.226 (7 Jan 2018 17:45:19 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 7 Jan 2018 17:45:19 +0000 (UTC) Cc: acm@muc.de, 29478@debbugs.gnu.org, npostavs@users.sourceforge.net To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Jan 07 18:45:14 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 1eYF0P-0001vK-CY for geb-bug-gnu-emacs@m.gmane.org; Sun, 07 Jan 2018 18:45:09 +0100 Original-Received: from localhost ([::1]:60614 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eYF2O-00087p-Ny for geb-bug-gnu-emacs@m.gmane.org; Sun, 07 Jan 2018 12:47:12 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59871) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eYF2I-00087d-2O for bug-gnu-emacs@gnu.org; Sun, 07 Jan 2018 12:47:06 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eYF2E-0004hx-3I for bug-gnu-emacs@gnu.org; Sun, 07 Jan 2018 12:47:06 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:59367) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eYF2D-0004hT-Vo for bug-gnu-emacs@gnu.org; Sun, 07 Jan 2018 12:47:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1eYF2D-00036P-Ku for bug-gnu-emacs@gnu.org; Sun, 07 Jan 2018 12:47:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 07 Jan 2018 17:47: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.151534720211900 (code B ref 29478); Sun, 07 Jan 2018 17:47:01 +0000 Original-Received: (at 29478) by debbugs.gnu.org; 7 Jan 2018 17:46:42 +0000 Original-Received: from localhost ([127.0.0.1]:39814 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eYF1u-00035s-JB for submit@debbugs.gnu.org; Sun, 07 Jan 2018 12:46:42 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:40466) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eYF1s-00035g-Pt for 29478@debbugs.gnu.org; Sun, 07 Jan 2018 12:46:41 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eYF1j-0004PB-IV for 29478@debbugs.gnu.org; Sun, 07 Jan 2018 12:46:35 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:44902) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eYF1Y-0004Jc-TB; Sun, 07 Jan 2018 12:46:20 -0500 Original-Received: from [176.228.60.248] (port=1681 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1eYF1Y-0002L1-AM; Sun, 07 Jan 2018 12:46:20 -0500 In-reply-to: (message from Stefan Monnier on Sun, 07 Jan 2018 10:31:38 -0500) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] 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:141877 Archived-At: > From: Stefan Monnier > Cc: acm@muc.de, 29478@debbugs.gnu.org, npostavs@users.sourceforge.net > Date: Sun, 07 Jan 2018 10:31:38 -0500 > > > In general, I see the idea is to show both down-mouse-N event and > > mouse-N event, both with "C-h c" and "C-h k". That could be okay, but > > why show undefined sequences? E.g, "C-h c S-mouse-1" shows this in > > the echo area: > > > > at that spot runs the command mouse-appearance-menu > > at that spot is undefined > > I did not make a special effort to do that, but I also didn't feel like > stripping them away because sometimes it's useful to know what is the > event name. E.g. you want to bind something to "shifted left mouse > click" because you noticed it doesn't do anything, so you already know > it's undefined, but you don't yet know how to spell it. We don't show unbound sequences anywhere else, except if they are explicitly asked about. Not sure why this case should be different. > 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. > > 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. > And I think it's important to preserve the order of the events. The order reversed is still an order ;-) > 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 ;-)