From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Moving point after character when clicking latter half of it Date: Sun, 09 Jul 2023 16:23:40 +0300 Message-ID: <83fs5x9q1v.fsf@gnu.org> References: <2255158.iZASKD2KPV@silef> <83fs5xbni9.fsf@gnu.org> <2160764.irdbgypaU6@anduin> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="16012"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Moritz Maxeiner Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Jul 09 15:24:31 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 1qIUOs-0003y5-Og for ged-emacs-devel@m.gmane-mx.org; Sun, 09 Jul 2023 15:24:30 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qIUO0-0000Dx-Dh; Sun, 09 Jul 2023 09:23:36 -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 1qIUNy-0000Dl-3x for emacs-devel@gnu.org; Sun, 09 Jul 2023 09:23:34 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qIUNx-00083l-IH; Sun, 09 Jul 2023 09:23:33 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=zeEdJnoUghMNH9nfS8IGWnPhITE93q4tdgOkUH4E22c=; b=hGfLe3gJgEP5 mXv3moSFr+li67fLESFNX+hmtPsWeZnPxNaPFB2SmAvisrEvKXgN8lt3YjlSWi+57HLqzIoDSPZiz EKtPWUKShZf7iVwwUKmFbA80BSXzRpBLL+GhstKAnxJl3yChhwDBctl/owRO64YMX9XKH2OMOXQNv vRGm9sekO4bdPICf9X0VzzxAQQ2V3KigPoXI6FB/Ildk3nmpbWTYKHdcTLnQyHrwz/MYNXOxfZz3I H7j9Y5ok2MUCmvJy+e4nzHrZNA6F/ST1lPaKSsoXb4+FW9YOzJt3KQ7kA+i0dojiyWDLPtBYIPsVg PinNEq1WvUQ+67oVTbcpYw==; Original-Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qIUNx-0007UN-2c; Sun, 09 Jul 2023 09:23:33 -0400 In-Reply-To: <2160764.irdbgypaU6@anduin> (message from Moritz Maxeiner on Sun, 09 Jul 2023 14:44:28 +0200) 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:307677 Archived-At: > 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. > 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.