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

[Moritz Maxeiner <mm@ucw.sh>]

On Sunday 9 July 2023 15:23:40 CEST Eli Zaretskii wrote:
> > From: Moritz Maxeiner <mm@ucw.sh>
> > Cc: emacs-devel@gnu.org
> > Date: Sun, 09 Jul 2023 14:44:28 +0200
> > 
> > > The right place is in buffer_posn_from_coords.  The change will be
> > > more complex there, but there's no way around this, since we want this
> > > change to affect only mouse clicks.
> > 
> > I am not surprised, given that I know little about Emacs internals at this
> > time. Thank you for the explanation. After looking at it a bit more I'm
> > not
> > sure if/how it can be accomplished without any modifications to
> > move_it_in_display_line_to, given that it uses/modifies the iterator in
> > many places and afaict we don't have access to glyph width outside of it.
> That's not true.  buffer_posn_from_coords calls several functions of
> the move_it_* family, including move_it_in_display_line_to itself, and
> the information that your proposed patch accessed via it->pixel_width
> is available to buffer_posn_from_coords through the 'struct it'
> variable it passes to those move_it_* functions.  The only
> complication is that you might need to call these functions more
> times, to asses whether this or the next glyph are closer to the click
> coordinates.

Ok, thanks for the corection. I might look into this, then.

> 
> > Would adding another option to move_it_in_display_line_to be acceptable?
> > That way only functions that explicitly select the new halfway behavior,
> > like I did with buffer_posn_from_coords in the new version of the poc
> > patch.
> 
> I don't see how this would work.  buffer_posn_from_coords calls
> move_it_to and move_it_in_display_line, it doesn't call
> move_it_in_display_line_to directly. 

It works because move_it_in_display_line forwards its op parameter to 
move_it_in_display_line_to. See the poc-0.2 patch I attached in my previous 
email.

> Are you suggesting to copy all 3
> of those functions, and only change them to account for this minor
> quirk?  That would be a terribly inelegant solution, since those
> functions are quite large and complex.

No, I just added a flag to move_operation_enum, which is passed by 
buffer_posn_from_coords to move_it_in_display_line in the op parameter, which 
already forwards it to move_it_in_display_line_to.

> 
> > That's good to hear. With respect to mouse dragging: Specifically in the
> > case that it's used to select text, yes, I would also like it to use the
> > new halfway behavior in that case, but I have not yet found where in
> > emacs' source code that change would need to happen.
> 
> Dragging is handled by the same code: all we need is to know the
> beginning and the end buffer position.  I was more asking about user
> expectations: those could be different when clicking to move point and
> when dragging.

Well, from my personal user expectation: If there is an option to toggle this 
halfway behavior on, I would expect it to also toggle it on for dragging, 
unless there's a second option explicitly for dragging. Personally, I think 
one option to toggle both would be good.