From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: Keymaps on images have pretty much stopped working Date: 07 Jan 2004 01:49:37 +0100 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: References: NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1073437560 562 80.91.224.253 (7 Jan 2004 01:06:00 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 7 Jan 2004 01:06:00 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Wed Jan 07 02:05:56 2004 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1Ae28y-0003k1-00 for ; Wed, 07 Jan 2004 02:05:56 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1Ae28y-0004Q8-00 for ; Wed, 07 Jan 2004 02:05:56 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.24) id 1Ae2xJ-00086T-EV for emacs-devel@quimby.gnus.org; Tue, 06 Jan 2004 20:57:57 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.24) id 1Ae2rQ-0005WN-Ds for emacs-devel@gnu.org; Tue, 06 Jan 2004 20:51:52 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1Ae2qs-0005LN-Mb for emacs-devel@gnu.org; Tue, 06 Jan 2004 20:51:49 -0500 Original-Received: from [62.226.12.191] (helo=localhost.localdomain) by monty-python.gnu.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.24) id 1Ae2qr-0005KZ-VH for emacs-devel@gnu.org; Tue, 06 Jan 2004 20:51:18 -0500 Original-Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.12.8/8.12.8) with ESMTP id i070neBJ006383 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Jan 2004 01:49:40 +0100 Original-Received: (from dak@localhost) by localhost.localdomain (8.12.8/8.12.8/Submit) id i070ncle006379; Wed, 7 Jan 2004 01:49:38 +0100 Original-To: no-spam@cua.dk (Kim F. Storm) In-Reply-To: Original-Lines: 60 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.2 Precedence: list List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:19053 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:19053 no-spam@cua.dk (Kim F. Storm) writes: > > David Kastrup writes: > > > Pressing C-h k followed by a middle mouse click on either icon causes > > > an error (with backtrace if debug-on-error is t). > > This works now. I get the following here (as an example): (translated from ) at that spot runs the command (lambda (event) (interactive "e") (preview-context-menu # event)) which is an interactive Lisp function. (anonymous EVENT) Not documented. This is quite correct and nice, except for the mysterious (anonymous EVENT) line which fails to look like something recognizable by ordinary humans. If I wanted to bicker (not me, would I?), I might also notive that the line breaking and indendation seems a bit odd. If I compare this with, say, C-g, I have C-g runs the command keyboard-quit which is an interactive compiled Lisp function in `simple'. It is bound to C-g. (keyboard-quit) Signal a `quit' condition. During execution of Lisp code, this character causes a quit directly. Now it is apparent that the (anonymous EVENT) line is probably supposed to be equivalent to the (keyboard-quit) line. I find even the (keyboard-quit) line quite disingenious: its purpose is not obvious. It becomes more apparent with commands like M-!: ESC ! (translated from !) runs the command shell-command which is an interactive compiled Lisp function in `simple'. It is bound to M-!, . (shell-command COMMAND &optional OUTPUT-BUFFER ERROR-BUFFER) Execute string COMMAND in inferior shell; display output, if any. With prefix argument, insert the COMMAND's output at point. [...] So it would appear to be a synopsis to go with the DOC string. I'd say at least an empty line before it would make sense (after all, it goes with the DOC string and _that_ is separated from it with a blank line). Personally, I'd say to remove that blank line above the DOC string and instead insert it before the function call synopsis. And I think in case of anonymous functions, the synopsis is wasted. Will we ever have a documentation string to go with it in the first place? Unlikely. And the arguments it takes are already apparent from the whole blurb quoting its lambda expression above. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum