From: Eli Zaretskii <eliz@gnu.org>
To: Moritz Maxeiner <mm@ucw.sh>
Cc: emacs-devel@gnu.org
Subject: Re: Moving point after character when clicking latter half of it
Date: Sun, 09 Jul 2023 16:23:40 +0300 [thread overview]
Message-ID: <83fs5x9q1v.fsf@gnu.org> (raw)
In-Reply-To: <2160764.irdbgypaU6@anduin> (message from Moritz Maxeiner on Sun, 09 Jul 2023 14:44:28 +0200)
> 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.
next prev parent reply other threads:[~2023-07-09 13:23 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-08 21:01 Moving point after character when clicking latter half of it Moritz Maxeiner
2023-07-09 6:35 ` Eli Zaretskii
2023-07-09 12:44 ` Moritz Maxeiner
2023-07-09 13:23 ` Eli Zaretskii [this message]
2023-07-09 13:51 ` Moritz Maxeiner
2023-07-09 14:14 ` Eli Zaretskii
2023-07-09 21:47 ` Moritz Maxeiner
2023-07-10 12:46 ` Eli Zaretskii
2023-07-10 14:43 ` [External] : " Drew Adams
2023-07-10 20:02 ` Moritz Maxeiner
2023-07-11 12:29 ` Eli Zaretskii
2023-07-11 13:10 ` Po Lu
2023-07-11 18:01 ` Moritz Maxeiner
2023-07-12 0:52 ` Po Lu
2023-07-12 19:58 ` Moritz Maxeiner
2023-07-12 21:17 ` Yuan Fu
2023-07-12 21:36 ` Moritz Maxeiner
2023-07-12 22:08 ` Yuan Fu
2023-07-13 5:27 ` Eli Zaretskii
2023-07-13 23:25 ` Yuan Fu
2023-07-13 0:31 ` Po Lu
2023-07-13 8:47 ` Eli Zaretskii
2023-07-21 19:04 ` Moritz Maxeiner
2023-07-21 23:57 ` Po Lu
2023-07-22 5:41 ` Eli Zaretskii
2023-07-22 10:07 ` Moritz Maxeiner
2023-07-22 11:31 ` Po Lu
2023-07-22 12:51 ` Eli Zaretskii
2023-07-22 15:28 ` Moritz Maxeiner
2023-07-22 15:51 ` Eli Zaretskii
2023-07-22 15:59 ` Moritz Maxeiner
2023-07-22 16:34 ` Eli Zaretskii
2023-07-22 19:10 ` Yuan Fu
2023-07-09 13:58 ` Yuri Khan
2023-07-09 12:40 ` Benjamin Riefenstahl
2023-07-09 12:47 ` Moritz Maxeiner
2023-07-09 13:37 ` Benjamin Riefenstahl
2023-07-09 15:15 ` [External] : " Drew Adams
2023-07-09 15:33 ` Moritz Maxeiner
2023-07-09 16:06 ` Drew Adams
2023-07-09 16:21 ` Brian Cully via Emacs development discussions.
2023-07-09 18:01 ` Jens Schmidt
2023-07-09 16:43 ` [External] : " Eli Zaretskii
2023-07-12 18:21 ` Benjamin Riefenstahl
2023-07-12 18:32 ` Eli Zaretskii
[not found] ` <12248204.O9o76ZdvQC@anduin>
[not found] ` <87ilac2kla.fsf@yahoo.com>
2023-07-22 14:48 ` Moritz Maxeiner
2023-07-22 15:26 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=83fs5x9q1v.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=mm@ucw.sh \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).