[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 16:23:40 +0300 |
> 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.
> 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. 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.
> 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.
- Moving point after character when clicking latter half of it, Moritz Maxeiner, 2023/07/09
- Re: Moving point after character when clicking latter half of it, Eli Zaretskii, 2023/07/09
- Re: Moving point after character when clicking latter half of it, Moritz Maxeiner, 2023/07/09
- Re: Moving point after character when clicking latter half of it,
Eli Zaretskii <=
- Re: Moving point after character when clicking latter half of it, Moritz Maxeiner, 2023/07/09
- Re: Moving point after character when clicking latter half of it, Eli Zaretskii, 2023/07/09
- Re: Moving point after character when clicking latter half of it, Moritz Maxeiner, 2023/07/09
- Re: Moving point after character when clicking latter half of it, Eli Zaretskii, 2023/07/10
- RE: [External] : Re: Moving point after character when clicking latter half of it, Drew Adams, 2023/07/10
- Re: Moving point after character when clicking latter half of it, Moritz Maxeiner, 2023/07/10
- Re: Moving point after character when clicking latter half of it, Eli Zaretskii, 2023/07/11
- Re: Moving point after character when clicking latter half of it, Po Lu, 2023/07/11
- Re: Moving point after character when clicking latter half of it, Moritz Maxeiner, 2023/07/11
- Re: Moving point after character when clicking latter half of it, Po Lu, 2023/07/11