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

[Richard Stallman]

      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 trying to read this and understand it, but having trouble parsing
it.  I can't really grasp the sequence of user actions and Emacs
behaviors.

It seems correct that Emacs uses the latest data to interpret a click;
what else should it do?  If the text is changing rapidly, in general
you are taking a risk by clicking on it, since what you intended to
click on could have moved or changed by the time the mouse button
makes contact.  But I don't understand enough to say that there is no
bug here.  I am not sure if this is a bug, or an unfortunate
consequence of correct Emacs actions, or just what the user deserves.

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

The buffer position tells you what image was clicked on.  Doesn't that
suffice for your immediate goal, which is to use just one keymap for
all the images?

We could add the relative position within in the image to the event,
and we could add other things to the event too.  Would someone like to
propose an upward compatible data representation that does the whole
job?