unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* Re: Keymaps on images have pretty much stopped working
       [not found]     ` <m3d69ztg1e.fsf@kfs-l.imdomain.dk>
@ 2004-01-06 23:45       ` Kim F. Storm
  2004-01-07  0:23         ` David Kastrup
                           ` (2 more replies)
  0 siblings, 3 replies; 5+ messages in thread
From: Kim F. Storm @ 2004-01-06 23:45 UTC (permalink / raw)
  Cc: emacs-devel


> David Kastrup <dak@gnu.org> writes:
> 
> > Ok, I'll try again to make an example.

I have just committed a fix.  This involves modifying the layout of
the mouse event.  As an added bonus, the actual width and height of
the image is now included in the event (so you can now make relative
position calculations).

I still need to fix the posn-* functions and correct the documentation.

> 
> >                                                And with larger
> > buffers with lots of icons I also had the situation where the wrong
> > icons thought they were clicked on.
> > 

I don't know for sure, but this may be fixed as well.  Please report if
it still occurs.


> > 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.

-- 
Kim F. Storm  http://www.cua.dk

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Keymaps on images have pretty much stopped working
  2004-01-06 23:45       ` Keymaps on images have pretty much stopped working Kim F. Storm
@ 2004-01-07  0:23         ` David Kastrup
  2004-01-07  0:49         ` David Kastrup
  2004-01-07  6:09         ` Eli Zaretskii
  2 siblings, 0 replies; 5+ messages in thread
From: David Kastrup @ 2004-01-07  0:23 UTC (permalink / raw)
  Cc: emacs-devel

no-spam@cua.dk (Kim F. Storm) writes:

> > David Kastrup <dak@gnu.org> writes:
> > 
> > > Ok, I'll try again to make an example.
> 
> I have just committed a fix.  This involves modifying the layout of
> the mouse event.  As an added bonus, the actual width and height of
> the image is now included in the event (so you can now make relative
> position calculations).

At first glance, this seems to work again.  Thanks.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Keymaps on images have pretty much stopped working
  2004-01-06 23:45       ` Keymaps on images have pretty much stopped working Kim F. Storm
  2004-01-07  0:23         ` David Kastrup
@ 2004-01-07  0:49         ` David Kastrup
  2004-01-07  6:09         ` Eli Zaretskii
  2 siblings, 0 replies; 5+ messages in thread
From: David Kastrup @ 2004-01-07  0:49 UTC (permalink / raw)
  Cc: emacs-devel

no-spam@cua.dk (Kim F. Storm) writes:

> > David Kastrup <dak@gnu.org> 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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Keymaps on images have pretty much stopped working
  2004-01-06 23:45       ` Keymaps on images have pretty much stopped working Kim F. Storm
  2004-01-07  0:23         ` David Kastrup
  2004-01-07  0:49         ` David Kastrup
@ 2004-01-07  6:09         ` Eli Zaretskii
  2004-01-07 11:03           ` Kim F. Storm
  2 siblings, 1 reply; 5+ messages in thread
From: Eli Zaretskii @ 2004-01-07  6:09 UTC (permalink / raw)
  Cc: dak, emacs-devel

> From: no-spam@cua.dk (Kim F. Storm)
> Date: 07 Jan 2004 00:45:38 +0100
> 
> I have just committed a fix.  This involves modifying the layout of
> the mouse event.

Does this affect in any way the text-mode platforms that support the
mouse, like MS-DOS and xt-mouse?

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Keymaps on images have pretty much stopped working
  2004-01-07  6:09         ` Eli Zaretskii
@ 2004-01-07 11:03           ` Kim F. Storm
  0 siblings, 0 replies; 5+ messages in thread
From: Kim F. Storm @ 2004-01-07 11:03 UTC (permalink / raw)
  Cc: emacs-devel

Eli Zaretskii <eliz@elta.co.il> writes:

> > From: no-spam@cua.dk (Kim F. Storm)
> > Date: 07 Jan 2004 00:45:38 +0100
> > 
> > I have just committed a fix.  This involves modifying the layout of
> > the mouse event.
> 
> Does this affect in any way the text-mode platforms that support the
> mouse, like MS-DOS and xt-mouse?
> 

The recent additions to the mouse event only adds extra elements to
the end of the existing list of information.  The modification I was
referring to was relative to my recent additions to the list, not
to the original contents of the list.  So it should be transparent.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2004-01-07 11:03 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <x5vfnsk99n.fsf@lola.goethe.zz>
     [not found] ` <E1AdDOG-0002DB-DH@fencepost.gnu.org>
     [not found]   ` <x5r7yfqz6c.fsf@lola.goethe.zz>
     [not found]     ` <m3d69ztg1e.fsf@kfs-l.imdomain.dk>
2004-01-06 23:45       ` Keymaps on images have pretty much stopped working Kim F. Storm
2004-01-07  0:23         ` David Kastrup
2004-01-07  0:49         ` David Kastrup
2004-01-07  6:09         ` Eli Zaretskii
2004-01-07 11:03           ` Kim F. Storm

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).