unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
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: Sun, 09 Jul 2023 23:47:51 +0200	[thread overview]
Message-ID: <3255279.aeNJFYEL58@silef> (raw)
In-Reply-To: <83edlh9npt.fsf@gnu.org>

[-- Attachment #1: Type: text/plain, Size: 3388 bytes --]

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.

[-- Attachment #2: emacs-29-move_it_in_display_line_to-nextglyphafterhalf-poc-0.3.patch --]
[-- Type: text/x-patch, Size: 1739 bytes --]

diff --git a/src/dispnew.c b/src/dispnew.c
index 65d9cf9b4e1..bd288286924 100644
--- a/src/dispnew.c
+++ b/src/dispnew.c
@@ -22,6 +22,7 @@ Copyright (C) 1985-1988, 1993-1995, 1997-2023 Free Software Foundation,
 
 #include "sysstdio.h"
 #include <stdlib.h>
+#include <math.h>
 #include <unistd.h>
 
 #include "lisp.h"
@@ -5611,6 +5612,9 @@ 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_point_alternate && to_x > it.current_x + ceil (it.pixel_width / 2.0))
+    move_it_in_display_line (&it, ZV, it.current_x + it.pixel_width, MOVE_TO_X);
+
   bidi_unshelve_cache (itdata, 0);
 
   Fset_buffer (old_current_buffer);
@@ -6468,6 +6472,7 @@ init_display_interactive (void)
 
   inverse_video = 0;
   cursor_in_echo_area = false;
+  mouse_point_alternate = false;
 
   /* Now is the time to initialize this; it's used by init_sys_modes
      during startup.  */
@@ -6788,6 +6793,11 @@ 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-point-alternate", mouse_point_alternate,
+	       doc: /* Non-nil means use alternate mode for mouse click selection of point.
+In alternate mode, if the clicked x coordinate exceeds half of the selected
+display element's width, put point after it.  */);
+
   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.

  reply	other threads:[~2023-07-09 21:47 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 [this message]
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=3255279.aeNJFYEL58@silef \
    --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).