[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Moving point after character when clicking latter half of it

From: Po Lu
Subject: Re: Moving point after character when clicking latter half of it
Date: Thu, 13 Jul 2023 08:31:30 +0800
User-agent: Gnus/5.13 (Gnus v5.13)

Moritz Maxeiner <mm@ucw.sh> writes:

> 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.

I don't see a problem with that, but please see below.

> diff --git a/doc/lispref/commands.texi b/doc/lispref/commands.texi
> index cd1745614eb..274c456d8c3 100644
> --- a/doc/lispref/commands.texi
> +++ b/doc/lispref/commands.texi
> @@ -1969,6 +1969,8 @@ events do not appear.  @xref{Mouse Tracking}.
>  When non-@code{nil}, mouse motion events are generated even for very
>  small movements.  Otherwise, motion events are not generated as long
>  as the mouse cursor remains pointing to the same glyph in the text.
> +Note that non-@code{nil} @code{mouse-prefer-closest-glyph} changes
> +that to the left/right half of the glyph under the mouse cursor instead.

I think this change is unnecessary and could at least be reworded or
moved to a more suitable venue.

>  @end defvar
>  @node Touchscreen Events
> @@ -2751,6 +2753,14 @@ If @var{whole} is non-@code{nil}, the @var{x} 
> coordinate is relative
>  to the entire window area including scroll bars, margins and fringes.
>  @end defun
> +@defvar mouse-prefer-closest-glyph
> +If you set this variable to non-@code{nil}, whenever you click or drag the 
> mouse,
> +instead of the point being always set in front of the clicked glyph, the 
> point
> +horizontally closest to the mouse position will be used.
> +So if you click in the left half of a glyph, point is set in front of it,
> +but if you click in the right half, point is set after it.
> +@end defvar

How about:

If this variable is non-@code{nil}, the @code{posn-point} of a mouse
position list will be set to the position of the glyph whose left most
position is closest to the mouse pointer, as opposed to the position of
the glyph underneath the mouse pointer itself.  For example, if
@code{posn-at-x-y} is called with @var{x} set to @code{9}, which is
contained within a character of width 10 positioned at column 0, the
point saved within the mouse position list will be after that character.


> +  DEFVAR_BOOL ("mouse-prefer-closest-glyph", mouse_prefer_closest_glyph,
> +            doc: /*  Non-nil means mouse position lists are reported relative

There is superfluous whitespace here.

>    if (window_resize_pixelwise)
>      {
>        width = height = 1;
> @@ -2950,6 +2953,16 @@ remember_mouse_glyph (struct frame *f, int gx, int gy, 
> NativeRectangle *rect)
>   store_rect:
>    STORE_NATIVE_RECT (*rect, gx, gy, width, height);
> +  if (mouse_prefer_closest_glyph)
> +    {
> +      int half_width = rect->width / 2;
> +      rect->width = half_width;
> +
> +      int bisection = rect->x + half_width;
> +      if (original_gx > bisection)
> +        rect->x = bisection;
> +    }

Instead of repeatedly loading from and storing to RECT, why not modify
width and height before the expansion of STORE_NATIVE_RECT?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]