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 10:31:38 -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> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1515339018 28316 195.159.176.226 (7 Jan 2018 15:30:18 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 7 Jan 2018 15:30:18 +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 16:30:13 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 1eYCtm-0006p2-7J for geb-bug-gnu-emacs@m.gmane.org; Sun, 07 Jan 2018 16:30:10 +0100 Original-Received: from localhost ([::1]:56558 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eYCvj-0007Ty-Oi for geb-bug-gnu-emacs@m.gmane.org; Sun, 07 Jan 2018 10:32:11 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41316) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eYCve-0007Tq-0q for bug-gnu-emacs@gnu.org; Sun, 07 Jan 2018 10:32:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eYCva-0002ma-2i for bug-gnu-emacs@gnu.org; Sun, 07 Jan 2018 10:32:06 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:59300) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eYCvZ-0002mL-V3 for bug-gnu-emacs@gnu.org; Sun, 07 Jan 2018 10:32:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1eYCvZ-0008Qy-Iy for bug-gnu-emacs@gnu.org; Sun, 07 Jan 2018 10:32: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 15:32: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.151533910832402 (code B ref 29478); Sun, 07 Jan 2018 15:32:01 +0000 Original-Received: (at 29478) by debbugs.gnu.org; 7 Jan 2018 15:31:48 +0000 Original-Received: from localhost ([127.0.0.1]:39748 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eYCvK-0008QW-Gw for submit@debbugs.gnu.org; Sun, 07 Jan 2018 10:31:48 -0500 Original-Received: from pmta31.teksavvy.com ([76.10.157.38]:36113) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eYCvJ-0008QK-0F for 29478@debbugs.gnu.org; Sun, 07 Jan 2018 10:31:45 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2GrjQAiPFJa/yyKSC1cHAEBAQQBAQoBAYM/gVqEOIURhHqOcYIClz6CAYVFAoQyQxQBAQEBAQEBAQEDaCiFJQEEASNWBQsLDQ0CGA4CAhQYMYo8CLA5gSaCJyECig0BAQEBBgIBJYEPhSaGNzaEYT2DF4JlBZIlgRSGNolvizBMi1mJdygPh0SYUzYjgVAyGggwgmiCUxwZgWwjik4BAQE X-IPAS-Result: A2GrjQAiPFJa/yyKSC1cHAEBAQQBAQoBAYM/gVqEOIURhHqOcYIClz6CAYVFAoQyQxQBAQEBAQEBAQEDaCiFJQEEASNWBQsLDQ0CGA4CAhQYMYo8CLA5gSaCJyECig0BAQEBBgIBJYEPhSaGNzaEYT2DF4JlBZIlgRSGNolvizBMi1mJdygPh0SYUzYjgVAyGggwgmiCUxwZgWwjik4BAQE X-IronPort-AV: E=Sophos;i="5.46,326,1511845200"; d="scan'208";a="16978208" Original-Received: from unknown (HELO pastel.home) ([45.72.138.44]) by smtp.teksavvy.com with ESMTP; 07 Jan 2018 10:31:39 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id 033506049F; Sun, 7 Jan 2018 10:31:38 -0500 (EST) In-Reply-To: <83zi5q997a.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 06 Jan 2018 19:40:57 +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:141867 Archived-At: >> If you want a patch that applies, the one below should work. > Thanks. It needs some more work. No doubt. > E.g., "C-h k C-mouse-1" signals an error: > help-fns--analyze-function: Symbol=E2=80=99s function definition is voi= d: nil Thanks. I'll look into fixing this... > and "C-h k C-mouse-3" followed by a menu selection asks for another > key or mouse click, although it already has got a full key sequence. ... and this. > 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. I think it's also useful to show to the user than there were two events. > 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). And I think it's important to preserve the order of the events. 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. Stefan