From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Yuan Fu Newsgroups: gmane.emacs.devel Subject: Re: Moving point after character when clicking latter half of it Date: Wed, 12 Jul 2023 15:08:55 -0700 Message-ID: References: <2255158.iZASKD2KPV@silef> <3242369.aeNJFYEL58@anduin> <76D3E9B6-C3BE-4E41-B228-AA252AAD4A11@gmail.com> <4870332.31r3eYUQgx@silef> Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.600.7\)) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="29340"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Po Lu , Eli Zaretskii , emacs-devel@gnu.org To: Moritz Maxeiner Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Jul 13 00:10: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 1qJi2F-0007TG-8T for ged-emacs-devel@m.gmane-mx.org; Thu, 13 Jul 2023 00:10:11 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qJi1I-0004dm-Lm; Wed, 12 Jul 2023 18:09:12 -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 1qJi1H-0004dL-2p for emacs-devel@gnu.org; Wed, 12 Jul 2023 18:09:11 -0400 Original-Received: from mail-pf1-x432.google.com ([2607:f8b0:4864:20::432]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qJi1F-0001q0-5C; Wed, 12 Jul 2023 18:09:10 -0400 Original-Received: by mail-pf1-x432.google.com with SMTP id d2e1a72fcca58-666ecb21f86so68821b3a.3; Wed, 12 Jul 2023 15:09:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1689199747; x=1691791747; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=5dxM+Z2IB0NpByhnZJ1TPDHyLBEifRg1Bv0xiWzCCDE=; b=KyELJ1egw3FioIy7cuHe3uugtPnqZg2+o8xGBX7RvtdEMjRmPNZFGawq6sbyaWEj5m oqZhGdXQ81PElVvtVV6xk3+OahdUsV9TxvMN/0Y8Pp2xrEpZAjp1VcpYrsa+708MhbgP 4nztkXRK3ANSpDbk50+jXye/Esa9sU82mpGhW+LYxpDFwEP+aY90W0RtfzBe9cmQjMX3 1kYWk9p5FHShKWwvXXfA0hiBDbS6aVSnYyTnV3O3Smy9iFVB94I6iRRSQQBadmfst6hu 0122maYfdhlQ5/4E4bhcXJj+MZw7YQKYePIa8Kwy9oOuR/YguDdgrWb1cAq/u+SnglM/ lceQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689199747; x=1691791747; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=5dxM+Z2IB0NpByhnZJ1TPDHyLBEifRg1Bv0xiWzCCDE=; b=Q3m0GCnMs0+fohD6GfycVtbutDybyG5mjxj4YlzU8LrzfdBTr1DtZA1B9Z08wRYP0V +Cs23uNHVzLdfGaoMHsPuMqhMni40VbKP/ozqs8yGad+22YF/rhw4HbAOBfoFvKgKnH6 w12CeciwQeBF4ON+4HXo0Eb3kljodfTzayhz88H2Xv1WdP5rAFxVKbfKC0ZEViMosqqp /3tqzvSkZ+0XZVS8WSJQ9LQPTH0O0ND6e+IHNaZDFr8ENzt810oCekzH+GiD5Zuu2AJR uwyly4fjBj8sK+9TztxyhiPg/c+Lv5tJelNdjmesB8p35vSdfOb5uFDNnrvxgjRMQocf KnGw== X-Gm-Message-State: ABy/qLYzebRiC279EK8iSh8AVCC+1IRa50UcGcJiXuycWEb0+h5YH+Wl NASrdllqbcfJxQeUIE3EbOU= X-Google-Smtp-Source: APBJJlEuKmeJXKSMvpoS/xZtmU5t8SuGQnnZg5DSTy3lNqvdr2fh98DdFT9YLJ+jdwByU2HQnbJFSQ== X-Received: by 2002:a05:6a00:2e96:b0:67e:6269:6ea8 with SMTP id fd22-20020a056a002e9600b0067e62696ea8mr27314500pfb.22.1689199747264; Wed, 12 Jul 2023 15:09:07 -0700 (PDT) Original-Received: from smtpclient.apple (cpe-172-117-161-177.socal.res.rr.com. [172.117.161.177]) by smtp.gmail.com with ESMTPSA id ey24-20020a056a0038d800b00666add7f047sm4014455pfb.207.2023.07.12.15.09.06 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 12 Jul 2023 15:09:06 -0700 (PDT) In-Reply-To: <4870332.31r3eYUQgx@silef> X-Mailer: Apple Mail (2.3731.600.7) Received-SPF: pass client-ip=2607:f8b0:4864:20::432; envelope-from=casouri@gmail.com; helo=mail-pf1-x432.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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:307799 Archived-At: > On Jul 12, 2023, at 2:36 PM, Moritz Maxeiner wrote: >=20 > On Wednesday, 12 July 2023 23:17:41 CEST Yuan Fu wrote: >>=20 >>> On Jul 12, 2023, at 12:58 PM, Moritz Maxeiner wrote: >>>=20 >>> On Wednesday 12 July 2023 02:52:01 CEST Po Lu wrote: >>>> Moritz Maxeiner writes: >>>>> I'm not clear on why that would make it wrong (as in incorrect = semantics). >>>>> It's definitely inefficient (though I've not noticed the overhead = in >>>>> practice), which is why I asked if there's a more elegant = solution. >>>>=20 >>>> The overhead is apparent when options such as >>>> `mouse-drag-and-drop-region' are enabled and the connection to the = X >>>> server is slow. >>>>=20 >>>>> Which this is, thank you very much for pointing that out. I've = changed >>>>> that >>>>> part of the patch accordingly, though this does unfortunately mean = that a >>>>> new function is required, due to multiple places setting the glyph >>>>> rectangle as it relates to dragging. >>>>=20 >>>> I find that difficult to believe. Would you please describe the = other >>>> callers of `remember_mouse_glyph' that make adjustments there >>>> impossible? >>>>=20 >>>> I asked you to make the change in `remember_mouse_glyph' because = that >>>> would avoid the need to modify each of the *term.[cm] files >>>> individually. Replacing it with a different function would miss = the >>>> point of the change. >>>=20 >>> My apologies, after rereading your previous message I realize I = misunderstood.=20 >>> I thought I was to put the changes after the remember_mouse_glyph = call (like I=20 >>> was previously asked to do for move_it_in_display_line instead of = modifying=20 >>> another xdisp.c function, move_it_in_display_line_to). My comment = derived from=20 >>> that misunderstanding as there are multiple calls to = remember_mouse_glyph that=20 >>> need to be affected. >>>=20 >>> I have adjusted the patch as requested (I think), added some = documentation in=20 >>> commands.texi, as well as a NEWS entry. I'm not sure about correct = placement /=20 >>> formatting of the latter two. >>>=20 >>> Btw. I'm not particularly happy about needed to add the = `original_gx'=20 >>> variable, but since the function seems to overwrite its argument, = which I need=20 >>> access to at its end (once the full glyph has been determined), I = don't see=20 >>> another option. I'm also not super happy about the needed division, = but I also=20 >>> don't see a way around that. If you know a more elegant solution I'd = be happy=20 >>> to hear it. >>>=20 >>>>=20 >>>>> Assuming this version of the implementation meets muster I will = work >>>>> on the etc/NEWS entry and can look into adding something to >>>>> (elisp)Accessing Mouse, as well. >>>>=20 >>>> Several other comments below: >>>>> +/* Function to bisect `glyph` into left and right halves, then >>>>> + replace it with the half in which `x` is. */ >>>>> + >>>>> +static void >>>>> +x_vertical_bisect_glyph(XRectangle *glyph, int x) >>>>> +{ >>>>> + int halfwidth =3D glyph->width / 2; >>>>> + glyph->width =3D halfwidth; >>>>> + >>>>> + int bisection =3D glyph->x + halfwidth; >>>>> + if (x > bisection) >>>>> + glyph->x =3D bisection; >>>>> +} >>>>=20 >>>> Please follow the GNU coding standards for both function = declarators and >>>> comments, by capitalizing (not quoting) arguments which appear in = the >>>> commentary, and placing a space between the identifier name and the >>>> opening parentheses of the parameter type list. Also, use the = active >>>> voice when describing the behavior of a function within its = commentary: >>>>=20 >>>> /* Replace *GLYPH, a rectangle containing the bounds of a glyph, = with >>>> the half of the rectangle containing the position X. */ >>>>=20 >>>> static void >>>> x_vertical_bisect_glyph (XRectangle *glyph, int x) >>>> { >>>> /* ... */ >>>> } >>>>=20 >>>> In addition, we don't use Markdown style quotes for code. When = quoting >>>> identifier names in the future, either write: >>>>=20 >>>> /* `foo' is used to perform ... */ >>>>=20 >>>> or >>>>=20 >>>> /* 'foo' is used to perform ... */ >>>>=20 >>>>> /* Function to report a mouse movement to the mainstream Emacs = code. >>>>>=20 >>>>> The input handler calls this. >>>>>=20 >>>>> @@ -14218,6 +14232,8 @@ x_note_mouse_movement (struct frame = *frame, const >>>>> XMotionEvent *event,>=20 >>>>> note_mouse_highlight (frame, event->x, event->y); >>>>> /* Remember which glyph we're now on. */ >>>>> remember_mouse_glyph (frame, event->x, event->y, r); >>>>>=20 >>>>> + if (mouse_prefer_closest_glyph) >>>>> + x_vertical_bisect_glyph(r, event->x); >>>>>=20 >>>>> dpyinfo->last_mouse_glyph_frame =3D frame; >>>>> return true; >>>>>=20 >>>>> } >>>>>=20 >>>>> @@ -14382,6 +14398,8 @@ x_fast_mouse_position (struct frame **fp, = int >>>>> insist, Lisp_Object *bar_window,>=20 >>>>> remember_mouse_glyph (f1, win_x, win_y, >>>>>=20 >>>>> &dpyinfo->last_mouse_glyph); >>>>>=20 >>>>> dpyinfo->last_mouse_glyph_frame =3D f1; >>>>>=20 >>>>> + if (mouse_prefer_closest_glyph) >>>>> + x_vertical_bisect_glyph(&dpyinfo->last_mouse_glyph, win_x); >>>>>=20 >>>>> *bar_window =3D Qnil; >>>>> *part =3D scroll_bar_nowhere; >>>>>=20 >>>>> @@ -14733,6 +14751,8 @@ XTmouse_position (struct frame **fp, int = insist, >>>>> Lisp_Object *bar_window,>=20 >>>>> dpyinfo =3D FRAME_DISPLAY_INFO (f1); >>>>> remember_mouse_glyph (f1, win_x, win_y, &dpyinfo- >>>> last_mouse_glyph); >>>>> dpyinfo->last_mouse_glyph_frame =3D f1; >>>>>=20 >>>>> + if (mouse_prefer_closest_glyph) >>>>> + x_vertical_bisect_glyph(&dpyinfo->last_mouse_glyph, = win_x); >>>>=20 >>>> Please place a space between the identifier name and the opening = brace >>>> of each function call. >>>>=20 >>>> However, implementing this feature shouldn't need changes to = xterm.c at >>>> all. Please make the change in `remember_mouse_glyph', not in = window >>>> system specific code. >>>=20 >>> Since that function (and calls to it) are now merged into=20 >>> `remember_mouse_glyph', I think these are solved by default. I'll = take more=20 >>> care next time, though, thank you for the = correction. >>=20 >> Sorry for joining late into the discussion. But I wonder if a Elisp = solution would suffice? Someone had requested this feature to me in the = past and this is my solution at the time. >>=20 >> Yuan >>=20 >>=20 >=20 > Thank you for the code. I've tried it out and it does seem to do the = same thing for a single mouse click, but it does not change the behavior = of mouse dragging (selection highlighting) in the same way, which I also = want/need (and this patch does). Ah, the code is just to show that similar things might be accomplishable = by modifying Elisp functions. I don=E2=80=99t suggest using it as-is. = Besides what you pointed out, it also uses advice, which is bad. Yuan=