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 15:51:10 +0200 Message-ID: <4513163.LvFx2qVVIh@anduin> References: <2255158.iZASKD2KPV@silef> <2160764.irdbgypaU6@anduin> <83fs5x9q1v.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="26557"; 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 15:52:17 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 1qIUpl-0006iK-0b for ged-emacs-devel@m.gmane-mx.org; Sun, 09 Jul 2023 15:52:17 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qIUor-0004kG-Ep; Sun, 09 Jul 2023 09:51:21 -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 1qIUop-0004jr-J7 for emacs-devel@gnu.org; Sun, 09 Jul 2023 09:51:19 -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 1qIUon-0003fa-Bc; Sun, 09 Jul 2023 09:51:19 -0400 Original-Received: from localhost (localhost [127.0.0.1]) by mail.ucw.sh (Postfix) with ESMTP id BF09597189; Sun, 9 Jul 2023 15:51:11 +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 ug_elwy0ggea; Sun, 9 Jul 2023 15:51:11 +0200 (CEST) Original-Received: from anduin.localnet (p200300d29747ecc2b2d2af557f4757a8.dip0.t-ipconnect.de [IPv6:2003:d2:9747:ecc2:b2d2:af55:7f47:57a8]) (Authenticated sender: mm@ucw.sh) by mail.ucw.sh (Postfix) with ESMTPSA; Sun, 9 Jul 2023 15:51:11 +0200 (CEST) In-Reply-To: <83fs5x9q1v.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:307679 Archived-At: On Sunday 9 July 2023 15:23:40 CEST Eli Zaretskii wrote: > > From: Moritz Maxeiner > > 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. Ok, thanks for the corection. I might look into this, then. > > > 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. > 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. No, I just added a flag to move_operation_enum, which is passed by buffer_posn_from_coords to move_it_in_display_line in the op parameter, which already forwards it to move_it_in_display_line_to. > > > 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. 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.