Re: No possibility of determining image position/object from click

[David.Kastrup@t-online.de (David Kastrup)]

Richard Stallman <rms@gnu.org> writes:

>     GNU Emacs is missing an API for finding out where a click occured.  If
>     I have a string or an image as part of a display property, or as a
>     before-string or after-string, the only way to let Emacs react to
>     clicks on different images differently is to generate individual
>     keymaps for each of them.

I have also encountered another "bug" in connection with that for
which an actual example is pretty hard to produce: if a displayed
window changes asynchronously because a sentinel is placing image
properties on screen, and Emacs is basically busy without getting to
redisplay, then tooltip displays (for example) will still pop up for
whatever the mouse cursor is covering, as a user would expect.  If one
does an actual _click_ on such an image, the positions(?) but at least
the keymaps that get consulted for this click are the keymaps that
belong to the display _after_ Emacs updates the screen.  This means,
for example, that you were sure to click on an image in the buffer
(and display and corresponding tooltip suggested you would), but if
Emacs actually gets to look at the click, it will instead yank the cut
buffer into a different location than that at the time of the click.

I am not sure this would be easy to fix: it would probably imply
having to associate things of relevance (object clicked on, buffer
position and a few other things) to an event at the time of the
click, or at least before redisplay destroys the information about
the screen state at the time of the event.

> I see.  All it provides is the buffer position, which won't tell
> you the position within the before-string.

Also, if a larger body of text is displayed as an image by way of a
'display property, the buffer position does not buy me anything (it
will probably be that of the first letter of the text).  This is
quite similar to the before-string problem, except that in that case
one does not have a string-object easily available with which to
associate.

> I think we should replace the buffer position with a list that gives
> the full story.
> 
>       Even then, you cannot find out the
>     relative coordinates of a click on such an image.
> 
> It does give the x and y pixel coordinates of the click.  If you can
> determine the coordinates of a corner of the image,

at the time of the click...

> you can subtract and get the relative position.  But I am not sure
> there is any way to determine the corner's coordinates, if the image
> comes from a before-string.

At least I have failed to see one.

> In principle, these are good features to add.  Do you have an
> immediate practical application for them?

Well, as you should remember from the amounts of display engine
related bug reports I sent in before Emacs-21.1 got released, I have
employed Emacs-21's new display engine for providing WYSIWYG-like
editing of LaTeX compositions (formulas, section headings, figures and
other configurable stuff).  Info/homepage/downloads at
<URL:http://preview-latex.sourceforge.net>.  Currently, we trace
clicks back to single images by giving each of them an individual
keymap with a keybinding to a quoted function call including the
image overlay.  It would be quite more convenient if all images could
just get the same keybinding.

A future plan is to provide relative positioning: click close to the
bottom of such an image, and you get placed close to the lower border
of the source text.  Another would be table editing: those are
currently one big image.  I could get the LaTeX component of
preview-latex to deliver the relative pixel coordinates in such a
table to Emacs, so that I can reliably edit a particular table cell
in the source code when the image gets clicked.

All of those refinements would require the relative position of the
click on the image.  The keymap tomfoolery has made it at least
possible to identify the image itself reliably, but the position
appears quite out of reach for me at the current point of time.

Would you be interested in getting info about the functions XEmacs
uses for reporting those properties of events, so that programmers of
external packages will have less work in order to make their stuff
work under both Emacsen?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum
Email: David.Kastrup@t-online.de