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 17:14:06 +0300 Message-ID: <83edlh9npt.fsf@gnu.org> References: <2255158.iZASKD2KPV@silef> <2160764.irdbgypaU6@anduin> <83fs5x9q1v.fsf@gnu.org> <4513163.LvFx2qVVIh@anduin> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="15080"; 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 16:15:11 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 1qIVBu-0003lN-Mm for ged-emacs-devel@m.gmane-mx.org; Sun, 09 Jul 2023 16:15:10 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qIVAp-0000aA-3E; Sun, 09 Jul 2023 10:14:03 -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 1qIVAm-0000Zw-UV for emacs-devel@gnu.org; Sun, 09 Jul 2023 10:14:00 -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 1qIVAm-0006PA-Ez; Sun, 09 Jul 2023 10:14:00 -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=wWL5OImYI8eBw7CDRH1uPPV8kL/xOifc95vHW4iXDM8=; b=RLEWPgYy6MHA 0KD/sIBUrFjSXBY2l1R3ujavbpNqSSE4pIabrShiN1Ve5d1nMZMa0G4pEceLBlyBTSTqcD7WgN9pP YWgNudXwx5s1SfzwhKdz1rBkZgdeJBTYzDr8XYWmiE4XEAgsFdjtvyLHhd1JqWSnWf71lVHySxp47 XRVz6D6m60rvU/bvJNY1FSa2mi3nAIUKSUkFoz/8msezMSom8wLEickpv8CCrPmq5gdhEsKLyBa9+ Ek3kUkJbVqIbV9mTJSy8LfgoztVi9WHxD1E/ihr6KYuDmBas1TVjSMeh8Tg3OWdMnt7b0oM6pScbG oP0FdJDuCgmusIGUd6/Ziw==; 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 1qIVAl-00080l-VF; Sun, 09 Jul 2023 10:14:00 -0400 In-Reply-To: <4513163.LvFx2qVVIh@anduin> (message from Moritz Maxeiner on Sun, 09 Jul 2023 15:51:10 +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:307682 Archived-At: > 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. > > > 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. > > 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.