emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Eli Zaretskii
Subject: Re: Moving point after character when clicking latter half of it
Date: Sun, 09 Jul 2023 17:14:06 +0300

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

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

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]