emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Keymaps on images have pretty much stopped working


From: David Kastrup
Subject: Re: Keymaps on images have pretty much stopped working
Date: 07 Jan 2004 01:49:37 +0100
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50

address@hidden (Kim F. Storm) writes:

> > David Kastrup <address@hidden> 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):

<mouse-3> (translated from <down-mouse-3> <mouse-3>) at that spot runs the 
command (lambda (event) (interactive "e") (preview-context-menu #<overlay from 
1327 to 1345 in diffspeed.tex> 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 <escape> !) runs the command shell-command
   which is an interactive compiled Lisp function in `simple'.
It is bound to M-!, <menu-bar> <tools> <shell>.
(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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]