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: Wed, 12 Jul 2023 23:36:12 +0200 Message-ID: <4870332.31r3eYUQgx@silef> References: <2255158.iZASKD2KPV@silef> <3242369.aeNJFYEL58@anduin> <76D3E9B6-C3BE-4E41-B228-AA252AAD4A11@gmail.com> 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="32874"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Po Lu , Eli Zaretskii , emacs-devel@gnu.org To: Yuan Fu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Jul 12 23:38:05 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 1qJhXA-0008L1-U8 for ged-emacs-devel@m.gmane-mx.org; Wed, 12 Jul 2023 23:38:05 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qJhWA-0005fz-CW; Wed, 12 Jul 2023 17:37:02 -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 1qJhW8-0005fk-QP for emacs-devel@gnu.org; Wed, 12 Jul 2023 17:37:00 -0400 Original-Received: from nephos.ucw.sh ([138.201.61.214] helo=mail.ucw.sh) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qJhW5-0007VA-7F; Wed, 12 Jul 2023 17:36:59 -0400 Original-Received: from localhost (localhost [127.0.0.1]) by mail.ucw.sh (Postfix) with ESMTP id 6CB2C99954; Wed, 12 Jul 2023 23:36:55 +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 ypd_YiJ-yqxh; Wed, 12 Jul 2023 23:36:54 +0200 (CEST) Original-Received: from silef.localnet (p200300d29747ecee5edd95f000ac748f.dip0.t-ipconnect.de [IPv6:2003:d2:9747:ecee:5edd:95f0:ac:748f]) (Authenticated sender: mm@ucw.sh) by mail.ucw.sh (Postfix) with ESMTPSA; Wed, 12 Jul 2023 23:36:54 +0200 (CEST) In-Reply-To: <76D3E9B6-C3BE-4E41-B228-AA252AAD4A11@gmail.com> Received-SPF: pass client-ip=138.201.61.214; 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:307798 Archived-At: On Wednesday, 12 July 2023 23:17:41 CEST Yuan Fu wrote: > > > On Jul 12, 2023, at 12:58 PM, Moritz Maxeiner wrote: > > > > 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. > >> > >> The overhead is apparent when options such as > >> `mouse-drag-and-drop-region' are enabled and the connection to the X > >> server is slow. > >> > >>> 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. > >> > >> I find that difficult to believe. Would you please describe the other > >> callers of `remember_mouse_glyph' that make adjustments there > >> impossible? > >> > >> 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. > > > > My apologies, after rereading your previous message I realize I misunderstood. > > I thought I was to put the changes after the remember_mouse_glyph call (like I > > was previously asked to do for move_it_in_display_line instead of modifying > > another xdisp.c function, move_it_in_display_line_to). My comment derived from > > that misunderstanding as there are multiple calls to remember_mouse_glyph that > > need to be affected. > > > > I have adjusted the patch as requested (I think), added some documentation in > > commands.texi, as well as a NEWS entry. I'm not sure about correct placement / > > formatting of the latter two. > > > > Btw. I'm not particularly happy about needed to add the `original_gx' > > variable, but since the function seems to overwrite its argument, which I need > > access to at its end (once the full glyph has been determined), I don't see > > another option. I'm also not super happy about the needed division, but I also > > don't see a way around that. If you know a more elegant solution I'd be happy > > to hear it. > > > >> > >>> 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. > >> > >> 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 = glyph->width / 2; > >>> + glyph->width = halfwidth; > >>> + > >>> + int bisection = glyph->x + halfwidth; > >>> + if (x > bisection) > >>> + glyph->x = bisection; > >>> +} > >> > >> 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: > >> > >> /* Replace *GLYPH, a rectangle containing the bounds of a glyph, with > >> the half of the rectangle containing the position X. */ > >> > >> static void > >> x_vertical_bisect_glyph (XRectangle *glyph, int x) > >> { > >> /* ... */ > >> } > >> > >> In addition, we don't use Markdown style quotes for code. When quoting > >> identifier names in the future, either write: > >> > >> /* `foo' is used to perform ... */ > >> > >> or > >> > >> /* 'foo' is used to perform ... */ > >> > >>> /* Function to report a mouse movement to the mainstream Emacs code. > >>> > >>> The input handler calls this. > >>> > >>> @@ -14218,6 +14232,8 @@ x_note_mouse_movement (struct frame *frame, const > >>> XMotionEvent *event,> > >>> note_mouse_highlight (frame, event->x, event->y); > >>> /* Remember which glyph we're now on. */ > >>> remember_mouse_glyph (frame, event->x, event->y, r); > >>> > >>> + if (mouse_prefer_closest_glyph) > >>> + x_vertical_bisect_glyph(r, event->x); > >>> > >>> dpyinfo->last_mouse_glyph_frame = frame; > >>> return true; > >>> > >>> } > >>> > >>> @@ -14382,6 +14398,8 @@ x_fast_mouse_position (struct frame **fp, int > >>> insist, Lisp_Object *bar_window,> > >>> remember_mouse_glyph (f1, win_x, win_y, > >>> > >>> &dpyinfo->last_mouse_glyph); > >>> > >>> dpyinfo->last_mouse_glyph_frame = f1; > >>> > >>> + if (mouse_prefer_closest_glyph) > >>> + x_vertical_bisect_glyph(&dpyinfo->last_mouse_glyph, win_x); > >>> > >>> *bar_window = Qnil; > >>> *part = scroll_bar_nowhere; > >>> > >>> @@ -14733,6 +14751,8 @@ XTmouse_position (struct frame **fp, int insist, > >>> Lisp_Object *bar_window,> > >>> dpyinfo = FRAME_DISPLAY_INFO (f1); > >>> remember_mouse_glyph (f1, win_x, win_y, &dpyinfo- > >> last_mouse_glyph); > >>> dpyinfo->last_mouse_glyph_frame = f1; > >>> > >>> + if (mouse_prefer_closest_glyph) > >>> + x_vertical_bisect_glyph(&dpyinfo->last_mouse_glyph, win_x); > >> > >> Please place a space between the identifier name and the opening brace > >> of each function call. > >> > >> 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. > > > > Since that function (and calls to it) are now merged into > > `remember_mouse_glyph', I think these are solved by default. I'll take more > > care next time, though, thank you for the correction. > > 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. > > Yuan > > 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).