Re: Moving point after character when clicking latter half of it

[Po Lu <luangruo@yahoo.com>]

Eli Zaretskii <eliz@gnu.org> writes:

> I'm not sure this is TRT.  In particular, it sounds like the change
> you made in xterm.c also overrides the Y coordinate condition? that
> doesn't sound right to me.  Po Lu, WDYT about this?
>
> The other changes LGTM, thanks.

This part of the patch

>    if (frame != dpyinfo->last_mouse_glyph_frame
>        || event->x < r->x || event->x >= r->x + r->width
> -      || event->y < r->y || event->y >= r->y + r->height)
> +      || event->y < r->y || event->y >= r->y + r->height
> +      || mouse_click_prefer_closest_char && EQ (track_mouse, Qdrag_tracking))

appears to special case a value of `track_mouse', and unconditionally
report mouse movement upon such a value being set, without considering
if the mouse pointer has moved to a position within the glyph that could
lead to a new position being reported.  This is not only wrong (since
Emacs shouldn't report mouse events differently even if `track_mouse' is
some other non-nil value), but is also inefficient, as setting
mouse_moved unnecessarily will result in an excessive number of mouse
motion events being reported.

I don't think we should disable the optimizations here entirely;
instead, it should be just as effective to save only the half of the
glyph containing the mouse pointer inside `remember_mouse_glyph' when
`mouse_click_prefer_closest_char' is true.

> +  DEFVAR_BOOL ("mouse-click-prefer-closest-char", mouse_click_prefer_closest_char,
> +	       doc: /* Non-nil means mouse click prefers the closest glyph as point.
> +When this is non-nil, clicking inside a glyph picks up the next glyph if the click
> +is closer to it then half the width of the clicked glyph.  */);
> +  mouse_click_prefer_closest_char = false;

Since this affects much more than just mouse clicks, shouldn't the
variable be named something else?  How about naming the variable
`mouse-prefer-closest-glyph', and using the following doc string
instead:

  Non-nil means mouse position lists are reported relative to the glyph
  closest to their coordinates.

  When non-nil, mouse position lists will be reported with their
  `posn-point' set to the position of the glyph closest to the mouse
  pointer, instead of the glyph immediately under.

Also, shouldn't the Lisp reference manual mention this variable?  In
(elisp)Accessing Mouse, for example.