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: [Patch] bug#29478: 26.0.90; `C-h k' followed by mouse clicks no longer shows down event Date: Sun, 28 Jan 2018 11:02:26 -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> <83shark8nl.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1517155297 10647 195.159.176.226 (28 Jan 2018 16:01:37 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 28 Jan 2018 16:01:37 +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 28 17:01:32 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 1efpOG-000127-VW for geb-bug-gnu-emacs@m.gmane.org; Sun, 28 Jan 2018 17:01:09 +0100 Original-Received: from localhost ([::1]:46317 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1efpQF-0007fM-Qr for geb-bug-gnu-emacs@m.gmane.org; Sun, 28 Jan 2018 11:03:11 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43957) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1efpQ9-0007dz-Hf for bug-gnu-emacs@gnu.org; Sun, 28 Jan 2018 11:03:06 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1efpQ6-0002zT-Dw for bug-gnu-emacs@gnu.org; Sun, 28 Jan 2018 11:03:05 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:38511) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1efpQ6-0002zF-95 for bug-gnu-emacs@gnu.org; Sun, 28 Jan 2018 11:03:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1efpQ5-0003Un-QG for bug-gnu-emacs@gnu.org; Sun, 28 Jan 2018 11:03: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, 28 Jan 2018 16:03: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.151715535013397 (code B ref 29478); Sun, 28 Jan 2018 16:03:01 +0000 Original-Received: (at 29478) by debbugs.gnu.org; 28 Jan 2018 16:02:30 +0000 Original-Received: from localhost ([127.0.0.1]:46408 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1efpPa-0003U0-CE for submit@debbugs.gnu.org; Sun, 28 Jan 2018 11:02:30 -0500 Original-Received: from pruche.dit.umontreal.ca ([132.204.246.22]:41508) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1efpPY-0003Ts-61 for 29478@debbugs.gnu.org; Sun, 28 Jan 2018 11:02:28 -0500 Original-Received: from pastel.home (lechon.iro.umontreal.ca [132.204.27.242]) by pruche.dit.umontreal.ca (8.14.7/8.14.1) with ESMTP id w0SG2QMO007870; Sun, 28 Jan 2018 11:02:27 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id 7788E605CC; Sun, 28 Jan 2018 11:02:26 -0500 (EST) In-Reply-To: <83shark8nl.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 27 Jan 2018 10:28:30 +0200") X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 2 Rules triggered EDT_SA_DN_PASS=0, RV6209=0 X-NAI-Spam-Version: 2.3.0.9418 : core <6209> : inlines <6344> : streams <1777352> : uri <2581394> 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:142609 Archived-At: >> +(defun help--first-event (keyseq) >> + (when (> (length keyseq) 0) >> + (aref keyseq (if (and (symbolp (aref keyseq 0)) >> + (> (length keyseq) 1) >> + (consp (aref keyseq 1))) >> + ;; Look at the second event when the first >> + ;; is a pseudo-event like `mode-line' of `left-fringe'. >> + 1 >> + 0)))) > > Should we perhaps test explicitly for pseudo-events, in case some day > we have events we don't want to skip? Or maybe have an assertion > here, for that future day? [ This code was moved from help--analyze-key, so improving it is orthogonal to the patch under discussion. Especially now that I see that the reason why I extracted this function (to use it in help-read-key-sequence) doesn't apply any more. ] You mean we should check that (aref keyseq 0) is within (mode-line left-fringe right-fringe ...)? I guess we could but what could we do with the result of the check? Signaling an error would not be very useful to the user. Note that the output of this function is only used to extract the modifiers of the event to then decide whether we add the text "at that spot" or not, so it's really not important. >> -(defun describe-key-briefly (&optional key insert untranslated) >> - "Print the name of the function KEY invokes. KEY is a string. >> +(defun describe-key-briefly (key-list &optional insert) >> + "Print the name of the functions KEY-LIST invokes. > > Is it a good idea to change the signature of this function? It's indeed the main issue I see with the patch: it completely changes the signature of several functions. > I'm sure it's used in many places, including outside Emacs. I couldn't find any use of those functions outside of Emacs (I did find uses as commands, but not as functions). But indeed I now see that there are some uses within Emacs, which I'd need to fix. I'll change the new code to accept the old calling convention. >> (defun help-read-key-sequence (&optional no-mouse-movement) >> - "Reads a key sequence from the user. >> -Returns a list of the form (KEY UP-EVENT), where KEY is the key >> -sequence, and UP-EVENT is the up-event that was discarded by >> -reading KEY, or nil. >> + "Read \"a\" key sequence from the user. > > Why "a" in quotes? Because it can also return several key sequences. But now that you mention it, it's better not to put those quotes and simply explain it better in the subsequent text. >> +Return a list of elements of the form (SEQ . RAW-SEQ), where SEQ is a key >> +sequence, and RAW-SEQ is its untranslated form. > This also changes the format of the return value in incompatible way, > doesn't it? Yes. > Is this incompatible change justified? Yes: we can't recover all the RAW-SEQs after the call (only the RAW-SEQ of the last element which can still be obtained from this-single-command-raw-keys), so the old return value format throws away information we need to emit complete information. In any case, this function is (or at least should be) internal, so I now renamed it with a "help--" prefix. If external callers show up, we may have to revisit this, but I couldn't find any. >> -(defun describe-key (&optional key untranslated up-event) >> - "Display documentation of the function invoked by KEY. >> -KEY can be any kind of a key sequence; it can include keyboard events, >> +(defun describe-key (key-list &optional buffer) >> + "Display documentation of the function invoked by KEY-LIST. >> +KEY-LIST can be any kind of a key sequence; it can include keyboard events, >> mouse events, and/or menu events. When calling from a program, > Same issue here. I'll also add compatibility to the old calling convention. > > We can probably come up with some heuristic to keep "at least one line > > of output" or something, but I think it's more useful for the user to > > report all the events and their binding or lack thereof since we don't > > really know what the user is looking for. > I'd prefer the "undefined" lines to appear only if none of the > possible interpretations is bound to a command, yes. Not sure what this means. Stefan