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

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

Richard Stallman <rms@gnu.org> writes:

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

Emacs uses data to interpret a click that has not yet made it to the
screen at the moment of the click.

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

This is not the problem, since this would just introduce a small
time window for thwarting the user.  But Emacs does not update the
screen while it is busy, which can easily last for a few seconds.  If
I click onto the screen during that time, buffer positions and
keymaps will be calculated corresponding to what the screen will look
like after the next screen update finally gets done.  This is hardly
what the user intended when clicking onto something.  Of course,
there is a problem for Emacs if the object displayed at the time of
the click has already been deleted, but this deletion has not yet
been reflected by a display update.

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

No.  I might have more than one image at a specific buffer position, I
might have overlays not covering any character.  The buffer position
will not tell me whether I clicked on the image of an empty overlay,
or on the character following it, or on which image from several
overlays at the same character position, or on some before-string or
after-string property of an overlay.

> Doesn't that suffice for your immediate goal, which is to use just
> one keymap for all the images?

Not really as well as to warrant changing the current behavior.

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

I would guess the internal structure of events need not be so very
much upward compatible as long as the interface routines to it (like
posn-xy or similar) returned the same values as before.

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