From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Moritz Maxeiner Newsgroups: gmane.emacs.devel Subject: Re: Moving point after character when clicking latter half of it Date: Sun, 09 Jul 2023 23:47:51 +0200 Message-ID: <3255279.aeNJFYEL58@silef> References: <2255158.iZASKD2KPV@silef> <4513163.LvFx2qVVIh@anduin> <83edlh9npt.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="nextPart3261490.44csPzL39Z" Content-Transfer-Encoding: 7Bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="7157"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Jul 09 23:49:34 2023 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1qIcHd-0001XY-VW for ged-emacs-devel@m.gmane-mx.org; Sun, 09 Jul 2023 23:49:34 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qIcGn-0007gr-Fy; Sun, 09 Jul 2023 17:48:41 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qIcGl-0007gg-Gn for emacs-devel@gnu.org; Sun, 09 Jul 2023 17:48:40 -0400 Original-Received: from mail.ucw.sh ([2a01:4f8:172:16d5:216:3eff:fefb:2fed]) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qIcGj-0004be-Jw; Sun, 09 Jul 2023 17:48:39 -0400 Original-Received: from localhost (localhost [127.0.0.1]) by mail.ucw.sh (Postfix) with ESMTP id 40063971F7; Sun, 9 Jul 2023 23:48:34 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mail.ucw.sh Original-Received: from mail.ucw.sh ([127.0.0.1]) by localhost (mail.ucw.sh [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id 5ikeKbAkyz9L; Sun, 9 Jul 2023 23:48:33 +0200 (CEST) Original-Received: from silef.localnet (p200300d29747ecc27c45485eecc4b465.dip0.t-ipconnect.de [IPv6:2003:d2:9747:ecc2:7c45:485e:ecc4:b465]) (Authenticated sender: mm@ucw.sh) by mail.ucw.sh (Postfix) with ESMTPSA; Sun, 9 Jul 2023 23:48:33 +0200 (CEST) In-Reply-To: <83edlh9npt.fsf@gnu.org> Received-SPF: pass client-ip=2a01:4f8:172:16d5:216:3eff:fefb:2fed; envelope-from=mm@ucw.sh; helo=mail.ucw.sh X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:307701 Archived-At: This is a multi-part message in MIME format. --nextPart3261490.44csPzL39Z Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" On Sunday, 9 July 2023 16:14:06 CEST Eli Zaretskii wrote: > > From: Moritz Maxeiner > > 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. --nextPart3261490.44csPzL39Z Content-Disposition: attachment; filename="emacs-29-move_it_in_display_line_to-nextglyphafterhalf-poc-0.3.patch" Content-Transfer-Encoding: 7Bit Content-Type: text/x-patch; charset="utf-8"; name="emacs-29-move_it_in_display_line_to-nextglyphafterhalf-poc-0.3.patch" 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 +#include #include #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. --nextPart3261490.44csPzL39Z--