Re: The display margin

[storm@cua.dk (Kim F. Storm)]

David Kastrup <dak@gnu.org> writes:

> Nick Roberts <nick@nick.uklinux.net> writes:
> 
> >  > I have just checked in fixes to improve event handling for mouse
> >  > clicks in the marginal areas and on the fringes.  Events now have
> >  > additional information:
> >  > 
> >  >    (WINDOW AREA-OR-POS (X . Y) TIMESTAMP OBJECT POS (COL . ROW))
> >  > 
> >  > AREA-OR-POS is not changed as such -- but it may now contain
> >  > left-fringe and right-fringe.
> >  > 
> >  > For clicks in the text area, POS is the same as AREA-OR-POS (the
> >  > buffer position clicked on).  For clicks in other areas, POS is
> >  > the buffer position of the first visible glyph on the
> >  > corresponding row.
> >  > 
> >  > As an example, try M-x gdba and click mouse-1 on the left margin
> >  > or fringe of a source window [it should toggle breakpoint on that
> >  > line].
> > 
> > Kim,
> > 
> > I like this very much.
> 
> The click information for GNU Emacs is quite insufficient, anyway.
> XEmacs, as far as I can remember, can tell from an event what object
> has been clicked on and what pixel relative to the object's origin
> has been hit.  With GNU Emacs, in contrast, you have to set up a
> separate keymap for every object in order to have a chance to find
> out which of several ones have been clicked, and no chance of finding
> the relative position at all.

The OBJECT part of an event (retrievable with the new posn-object
function) will give you the object clicked on, that is, if the object
you click on is an overlay string or display property string or image,
then the string and a character position in that string is returned.

I agree that for images, a relative pixel coordiante would be useful too;
I'll look into that.

> 
> And the object/click correlation is done at the time when you query
> the event, not when the click was done: if you click in order to do a
> cut&paste operation on some buffer, and Emacs churns away internally
> at the time, finally places a dialog box "Explode now?" on the
> screen, then finally processes the click event, it will associate at
> it with the exploding object instead of what was on the screen at the
> time of the click.

Yes, that may be true -- mouse events are put into the normal input
queue, so if there are other events (like async process i/o) going on
before emacs processes the input queue, it may hit the wrong object
before it gets a change to process it.

But I don't quite follow the line of thought above; emacs must have
processed the mouse event if it displays an "Explode now?" dialog box;
and as such, it must have a handle to the clicked-on object prior to
showing that dialog box.  Can you show me a piece of code which
demonstrates the problem?

> 
> I digress.  Anyway, I want more information from clicks.  At the
> very least, the object they appeared on.

Doesn't this work with my latest changes?

++kfs