Re: Selection threshold with mouse

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Sun, 20 Jul 2014 11:37:34 -0400
> 
> > That's the "silly iteration" I had in mind: the 2nd part of this is
> > the tricky one, because all we know from posn-at-x-y and its ilk is
> > the pixel width of the object at the coordinates we pass to the
> > function; we don't know the coordinates where the object starts.
> 
> 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?).  In any case, we cannot rely on glyph matrices alone,
because that would severely limit the usefulness of such an API.
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.  Also, some modes, like linum-mode, never let you have an
up-to-date glyph matrix.

For these reasons, posn-at-x-y etc. do not rely on glyph matrices, but
instead simulate display.

> > Actually, I disagree: every other GUI app I could try behaves like the
> > OP asked by default, so I see no reason for Emacs to offer an option
> > here.
> 
> They do, but not for all operations.  E.g. if you click on the rightmost
> pixel of a hyperlink, your browser will happily consider that the click
> was on the hyperlink, not on the position right after that one.

I think hyperlinks are the odd one out, and not directly related to
the issue here, which is where to put point given a click, especially
in the context of highlighting the region.