From: Moritz Maxeiner <mm@ucw.sh>
To: Eli Zaretskii <eliz@gnu.org>
Cc: emacs-devel@gnu.org
Subject: Re: Moving point after character when clicking latter half of it
Date: Mon, 10 Jul 2023 22:02:23 +0200 [thread overview]
Message-ID: <3431515.QJadu78ljV@anduin> (raw)
In-Reply-To: <83ttuc7x3k.fsf@gnu.org>
[-- Attachment #1: Type: text/plain, Size: 1406 bytes --]
Thank you for your suggestions (I've not quoted them in this reply for
brevity). Unless I've overlooked something I've implemented them all, except
for the etc/NEWS entry.
On Monday 10 July 2023 14:46:39 CEST Eli Zaretskii wrote:
> It should also be called out in etc/NEWS.
I agree, but I feel this should be done in the last iteration of the patch,
once all other changes are done. Which leads me to the next point:
I had to add another piece of code to src/xterm.c, because while text
selection via mouse dragging did automatically factor in the new optional
behavior after releasing the mouse, it did not update the highlighted /
selected region, as that requires mouse-movement events to be triggered, which
are picked up in mouse.el via mouse-drag-track, which then updated the
highlighted region. That event, however, is only triggered by leaving the
previous glyph, so we need to trigger it while still being on the glyph.
I tried sending the event only when crossing the vertical midline of the
glyph, but for a reason unknown to me, sending the event only once did not
result in the highlight being updated when dragging the mouse to the right,
only to the left.
As a workaround, I now trigger the event always while dragging with the
optional behavior on. If there is a more elegant solution I don't see I'd
welcome it. For now the overhead doesn't seem noticeable in practice.
[-- Attachment #2: emacs-29-move_it_in_display_line_to-nextglyphafterhalf-poc-0.4.patch --]
[-- Type: text/x-patch, Size: 3071 bytes --]
diff --git a/lisp/cus-start.el b/lisp/cus-start.el
index 054683d7cf6..489471f8eab 100644
--- a/lisp/cus-start.el
+++ b/lisp/cus-start.el
@@ -231,6 +231,7 @@ minibuffer-prompt-properties--setter
(inverse-video display boolean)
(visible-bell display boolean)
(no-redraw-on-reenter display boolean)
+ (mouse-click-prefer-closest-char display boolean)
;; doc.c
(text-quoting-style display
diff --git a/src/dispnew.c b/src/dispnew.c
index 65d9cf9b4e1..5fcecd5811d 100644
--- a/src/dispnew.c
+++ b/src/dispnew.c
@@ -5611,6 +5611,15 @@ buffer_posn_from_coords (struct window *w, int *x, int *y, struct display_pos *p
argument is ZV to prevent move_it_in_display_line from matching
based on buffer positions. */
move_it_in_display_line (&it, ZV, to_x, MOVE_TO_X);
+ if (mouse_click_prefer_closest_char)
+ {
+ int next_x = it.current_x + it.pixel_width;
+ int before_dx = to_x - it.current_x;
+ int after_dx = next_x - to_x;
+ if (before_dx > after_dx)
+ move_it_in_display_line (&it, ZV, next_x, MOVE_TO_X);
+ }
+
bidi_unshelve_cache (itdata, 0);
Fset_buffer (old_current_buffer);
@@ -6788,6 +6797,12 @@ syms_of_display (void)
DEFVAR_BOOL ("cursor-in-echo-area", cursor_in_echo_area,
doc: /* Non-nil means put cursor in minibuffer, at end of any message there. */);
+ DEFVAR_BOOL ("mouse-click-prefer-closest-char", mouse_click_prefer_closest_char,
+ doc: /* Non-nil means mouse click prefers the closest glyph as point.
+When this is non-nil, clicking inside a glyph picks up the next glyph if the click
+is closer to it then half the width of the clicked glyph. */);
+ mouse_click_prefer_closest_char = false;
+
DEFVAR_LISP ("glyph-table", Vglyph_table,
doc: /* Table defining how to output a glyph code to the frame.
If not nil, this is a vector indexed by glyph code to define the glyph.
diff --git a/src/xterm.c b/src/xterm.c
index 5840b15bcb7..44dcc8b1761 100644
--- a/src/xterm.c
+++ b/src/xterm.c
@@ -14206,11 +14206,13 @@ x_note_mouse_movement (struct frame *frame, const XMotionEvent *event,
}
- /* Has the mouse moved off the glyph it was on at the last sighting? */
+ /* Has the mouse moved off the glyph it was on at the last sighting?
+ Is the mouse being dragged while we need to keep point to the nearest glyph? */
r = &dpyinfo->last_mouse_glyph;
if (frame != dpyinfo->last_mouse_glyph_frame
|| event->x < r->x || event->x >= r->x + r->width
- || event->y < r->y || event->y >= r->y + r->height)
+ || event->y < r->y || event->y >= r->y + r->height
+ || mouse_click_prefer_closest_char && EQ (track_mouse, Qdrag_tracking))
{
frame->mouse_moved = true;
frame->last_mouse_device = device;
@@ -31705,4 +31707,6 @@ syms_of_xterm (void)
If that is still too slow, setting this variable to the symbol
`really-fast' will make Emacs return only cached values. */);
Vx_use_fast_mouse_position = Qnil;
+
+ DEFSYM (Qdrag_tracking, "drag-tracking");
}
next prev parent reply other threads:[~2023-07-10 20:02 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
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 [this message]
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=3431515.QJadu78ljV@anduin \
--to=mm@ucw.sh \
--cc=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
/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).