Re: Selection threshold with mouse

[Eli Zaretskii <eliz@gnu.org>]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Sun, 20 Jul 2014 12:44:22 -0400
> 
> >> Hmm... but don't the display matrices contain the needed info (i.e. the
> >> "left-pixel boundary position"), since it's needed to react to an
> >> expose event?
> > Not sure I follow (what does an expose event have to do with the issue
> > at hand?).
> 
> An expose event comes with pixel coordinates and we need to respond by
> drawing chars at the proper pixel positions, so we clearly need to be
> able to find the chars placed at those pixel positions as well as their
> pixel boundaries.

Yes, but in these cases we can always err on the safe side,
i.e. redraw more than strictly needed.  We cannot use this strategy in
the case in point.

> > E.g., you will be unable to use it in a function that is called
> > several times in a row, like via a numeric argument or from a keyboard
> > macro.
> 
> We could make it update glyph matrices if/when needed.

That would make Emacs much slower than it is now, because now we never
enter redisplay as long as a command runs.  You suggest to interrupt a
running command by doing a large portion of redisplay, which will slow
us down.

> > For these reasons, posn-at-x-y etc. do not rely on glyph matrices, but
> > instead simulate display.
> 
> Then I don't understand why the precise pixel position is not available.

Because the existing methods are glyph-granular, not pixel-granular.
When you tell them to stop at pixel coordinate X, they move one
"display element" (e.g., character or image) at a time, and they stop
when they are _at_or_after_ the glyph whose pixel width includes the
coordinate X.  This doesn't reliably tell you where the glyph at X
starts on display.

These methods were never designed to return the kind of information
and with the kind of accuracy that is required for implementing the
requirement we are discussing.