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

[Moritz Maxeiner]

On Tuesday 11 July 2023 15:10:24 CEST Po Lu wrote:
> 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.

True, though it is still conditional on the optional feature being enabled 
(both mouse_click_prefer_closest_char and drag_tracking, which mouse.el sets, 
need to be true). That being said I tried before to have this only be reported 
when the mouse crosses halfway point (without modifying the glyph itself) but 
that didn't really work.

> 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'm not clear on why that would make it wrong (as in incorrect semantics). 
It's definitely inefficient (though I've not noticed the overhead in practice), 
which is why I asked if there's a more elegant solution.

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

Which this is, thank you very much for pointing that out. I've changed that 
part of the patch accordingly, though this does unfortunately mean that a new 
function is required, due to multiple places setting the glyph rectangle as it 
relates to dragging.


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

I've included those changes.

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

Assuming this version of the implementation meets muster I will work on the 
etc/NEWS entry and can look into adding something to (elisp)Accessing Mouse, 
as well.

emacs-29-move_it_in_display_line_to-nextglyphafterhalf-poc-0.5.patch
Description: Text Data