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

[Moritz Maxeiner]

On Sunday, 9 July 2023 16:14:06 CEST Eli Zaretskii wrote:
> > From: Moritz Maxeiner <mm@ucw.sh>
> > Cc: emacs-devel@gnu.org
> > Date: Sun, 09 Jul 2023 15:51:10 +0200
> > 
> > On Sunday 9 July 2023 15:23:40 CEST Eli Zaretskii wrote:
> > > 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.
> 
> Basically, you need to examine it.current_x after the last call to
> move_it_in_display_line returns, and if it is closer to
> to_x+it.pixel_width than to to_x, call move_it_in_display_line again
> to get to to_x+it.pixel_width.

Thanks, I've implemented something along those lines. Same source position,
but the check is if to_x exceeds half of the selected display element's width
and if so rerun move_it_in_display_line at it.current_x + it.pixel_width
(so first pixel of the next display element).
Running it at to_x+it.pixel_width might run into trouble if the current display
element is a lot wider than the one after it.

I've also added an option mouse_point_alternate (temporary name, didn't know
what else to call it, open to suggestions) to enable it. It defaults to off.

> 
> > > > 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.
> 
> Oh, you mean another value for the move_operation_enum enumeration?
> That's possible, but sounds too much, since all you need is another
> call to move_it_in_display_line.

Well, it is certainly a less invasive change that way so I'm going with it for 
now.
But I have to say it feels wasteful to call the function twice instead of having
it deal with it "correctly" the first time around with an option.

> 
> > > 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.
> 
> Maybe.  We will need to hear more opinions, I guess.
> 

Sure, until then next up for me is figuring out where I'll need to make
mouse dragging behave in line with the "mouse-alternate-point" mode.

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