bug#47360: 27.1; using 'bar cursor, mouseclick is rounded to the wrong char position

bug#47360: 27.1; using 'bar cursor, mouseclick is rounded to the wrong char position

[Julian Rohrhuber via Bug reports for GNU Emacs, the Swiss army knife of text editors]

[-- Attachment #1: Type: text/plain, Size: 1990 bytes --]

When using 'bar as cursor, the click location is truncated to the value before the character one clicks on (as expected when using a 'box). When using a 'bar, however, one expects that the "hill" is in the center of each character, and the valley between them. I've made an illustration, where the green color shows the watershed, so to speak.

This behavior feels subtly broken.

A solution to the issue has been suggested https://emacs.stackexchange.com/questions/20279/mouse-pointer-between-characters-and-the-text-cursor-misplacement

Using the modified function posn-set-point below fixes the issue for me. I find the behavior also reasonable for 'box, but that might be a matter of discussion.

(defun posn-set-point (position)
"Move point to POSITION.
Select the corresponding window as well."
(if (not (windowp (posn-window position)))
(error "Position not in text area of window"))
(select-window (posn-window position))
(let ((pos (posn-point position)))
(if (numberp pos)
(goto-char (if (and (eq 'bar (or (car-safe cursor-type) cursor-type))
(< pos (point-max))
(consp position)
(numberp (car-safe (posn-object-x-y position)))
(numberp (car-safe (posn-object-width-height position)))
(> (* 2 (car (posn-object-x-y position)))
(car (posn-object-width-height position))))
(1+ pos)
pos)))))

Configured features:
NOTIFY KQUEUE ACL GNUTLS LIBXML2 ZLIB TOOLKIT_SCROLL_BARS NS MODULES
THREADS JSON PDUMPER

Important settings:
value of $LANG: en_DE.UTF-8
locale-coding-system: utf-8-unix

Major mode: Markdown

Minor modes in effect:
shell-dirtrack-mode: t
org-roam-mode: t
recentf-mode: t
ivy-mode: t
desktop-save-mode: t
show-paren-mode: t
tooltip-mode: t
global-eldoc-mode: t
eldoc-mode: t
electric-indent-mode: t
mouse-wheel-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
line-number-mode: t
global-visual-line-mode: t
visual-line-mode: t
transient-mark-mode: t

[-- Attachment #2.1: Type: text/html, Size: 4124 bytes --]

[-- Attachment #2.2: ohnehin.jpg --]
[-- Type: image/jpeg, Size: 11090 bytes --]

bug#47360: 27.1; using 'bar cursor, mouseclick is rounded to the wrong char position

[Eli Zaretskii]

> Date: Wed, 24 Mar 2021 07:42:28 +0000
> From:  Julian Rohrhuber via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
> 
> When using 'bar as cursor, the click location is truncated to the value before the character one clicks on (as expected when using a 'box). When using a 'bar, however, one expects that the "hill" is in the center of each character, and the valley between them. I've made an illustration, where the green color shows the watershed, so to speak.
> 
> This behavior feels subtly broken.
> 
> A solution to the issue has been suggested https://emacs.stackexchange.com/questions/20279/mouse-pointer-between-characters-and-the-text-cursor-misplacement
> 
> Using the modified function posn-set-point below fixes the issue for me. I find the behavior also reasonable for 'box, but that might be a matter of discussion.

I don't think I see the problem you describe.  If I click exactly on
the bar cursor, the cursor doesn't move, as I'd expect.

In any case, please note that in Emacs the bar cursor is never exactly
between two characters, it is at the left side of a character cell, so
closer to the character on the right (for left-to-right text).

bug#47360: 27.1; using 'bar cursor, mouseclick is rounded to the wrong char position

[Julian Rohrhuber via Bug reports for GNU Emacs, the Swiss army knife of text editors]

> On 24. Mar 2021, at 18:25, Eli Zaretskii <eliz@gnu.org> wrote:
>
>>
>> Date: Wed, 24 Mar 2021 07:42:28 +0000
>> From:  Julian Rohrhuber via "Bug reports for GNU Emacs,
>> the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
>>
>> When using 'bar as cursor, the click location is truncated to the value before the character one clicks on (as expected when using a 'box). When using a 'bar, however, one expects that the "hill" is in the center of each character, and the valley between them. I've made an illustration, where the green color shows the watershed, so to speak.
>>
>> This behavior feels subtly broken.
>>
>> A solution to the issue has been suggested https://emacs.stackexchange.com/questions/20279/mouse-pointer-between-characters-and-the-text-cursor-misplacement
>>
>> Using the modified function posn-set-point below fixes the issue for me. I find the behavior also reasonable for 'box, but that might be a matter of discussion.
>
> I don't think I see the problem you describe.  If I click exactly on
> the bar cursor, the cursor doesn't move, as I'd expect.

Sorry, I may not have described the issue well.

When clicking into a text, at a random position, the  position where the cursor jumps to is calculated. Now this is a bit subtle: when you click on a character, does the cursor jump to the left of that character or to its right?

When in box mode, it jumps to the left, and here this is correct.

But when in bar mode, it should jump to the right when the click is right of the middle of the character, and only left when to its left of the middle.

Instead, it also jumps to the left.

> In any case, please note that in Emacs the bar cursor is never exactly
> between two characters, it is at the left side of a character cell, so
> closer to the character on the right (for left-to-right text).

That is completely fine, what matters is only how the right-vs-left is calculated.

bug#47360: 27.1; using 'bar cursor, mouseclick is rounded to the wrong char position

[Eli Zaretskii]

> Date: Wed, 24 Mar 2021 17:38:41 +0000
> From: Julian Rohrhuber <rohrhuber@protonmail.com>
> Cc: 47360@debbugs.gnu.org
> 
> When clicking into a text, at a random position, the  position where the cursor jumps to is calculated. Now this is a bit subtle: when you click on a character, does the cursor jump to the left of that character or to its right?
> 
> When in box mode, it jumps to the left, and here this is correct.
> 
> But when in bar mode, it should jump to the right when the click is right of the middle of the character, and only left when to its left of the middle.

Why should it jump to the right?  You click on a character, then point
is set _before_ that character (point is always between 2 characters
in Emacs).  So the bar cursor will be to the left of that character.

> Instead, it also jumps to the left.

As I'd expect.

bug#47360: 27.1; using 'bar cursor, mouseclick is rounded to the wrong char position

[Lars Ingebrigtsen]

Julian Rohrhuber <rohrhuber@protonmail.com> writes:

> But when in bar mode, it should jump to the right when the click is
> right of the middle of the character, and only left when to its left
> of the middle.
>
> Instead, it also jumps to the left.

The cursor shape is purely cosmetic at present, I think.  Your
suggestion to add semantics to the bar shape makes some intuitive sense,
but I'm afraid that might leave us open to user interface
inconsistencies unless considered carefully.

Are there other instances we might want to do something based on the
cursor shape other than setting point with the mouse, I wonder?  Would
"marking an area to the left" (i.e., clicking on a character and then
dragging to the left) be handled differently?  In that case, dragging
starting with the mouse at any point right of the bar cursor should
perhaps include the character under point, and not just at the half-way
point?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#47360: 27.1; using 'bar cursor, mouseclick is rounded to the wrong char position

[Julian Rohrhuber via Bug reports for GNU Emacs, the Swiss army knife of text editors]

> On 24. Mar 2021, at 19:39, Lars Ingebrigtsen <larsi@gnus.org> wrote:
>
>
> Julian Rohrhuber <rohrhuber@protonmail.com> writes:
>
>> But when in bar mode, it should jump to the right when the click is
>> right of the middle of the character, and only left when to its left
>> of the middle.
>>
>> Instead, it also jumps to the left.
>
> The cursor shape is purely cosmetic at present, I think.  Your
> suggestion to add semantics to the bar shape makes some intuitive sense,
> but I'm afraid that might leave us open to user interface
> inconsistencies unless considered carefully.

yes, I definitely see your point here. The concept of a bar is indeed more than cosmetic, even if perhaps the differences are easily taken into account.

For those who use other editors are habituated very deeply to a specific behaviour of the bar, and anything that deviates from this feels subtly but clearly broken.


> Are there other instances we might want to do something based on the
> cursor shape other than setting point with the mouse, I wonder?  Would
> "marking an area to the left" (i.e., clicking on a character and then
> dragging to the left) be handled differently?  In that case, dragging
> starting with the mouse at any point right of the bar cursor should
> perhaps include the character under point, and not just at the half-way
> point?

I've checked with some editors, e.g atom (using huge font is easiest), the selection works just like the jump (so it is a selection of zero length). When you click to the right of the middle of a character and then drag to the left, the character will be included. If you drag to the right it will not be included.

bug#47360: 27.1; using 'bar cursor, mouseclick is rounded to the wrong char position

[Julian Rohrhuber via Bug reports for GNU Emacs, the Swiss army knife of text editors]

> On 24. Mar 2021, at 20:08, Julian Rohrhuber <rohrhuber@protonmail.com> wrote:
>
>> On 24. Mar 2021, at 19:39, Lars Ingebrigtsen <larsi@gnus.org> wrote:
>>
>>
>> Julian Rohrhuber <rohrhuber@protonmail.com> writes:
>>
>>> But when in bar mode, it should jump to the right when the click is
>>> right of the middle of the character, and only left when to its left
>>> of the middle.
>>>
>>> Instead, it also jumps to the left.
>>
>> The cursor shape is purely cosmetic at present, I think.  Your
>> suggestion to add semantics to the bar shape makes some intuitive sense,
>> but I'm afraid that might leave us open to user interface
>> inconsistencies unless considered carefully.
>
> yes, I definitely see your point here. The concept of a bar is indeed more than cosmetic, even if perhaps the differences are easily taken into account.
>
> For those who use other editors are habituated very deeply to a specific behaviour of the bar, and anything that deviates from this feels subtly but clearly broken.
>
>
>> Are there other instances we might want to do something based on the
>> cursor shape other than setting point with the mouse, I wonder?  Would
>> "marking an area to the left" (i.e., clicking on a character and then
>> dragging to the left) be handled differently?  In that case, dragging
>> starting with the mouse at any point right of the bar cursor should
>> perhaps include the character under point, and not just at the half-way
>> point?
>
> I've checked with some editors, e.g atom (using huge font is easiest), the selection works just like the jump (so it is a selection of zero length). When you click to the right of the middle of a character and then drag to the left, the character will be included. If you drag to the right it will not be included.


There is one more case where one can feel the difference: when selecting with the mouse and dragging to the right, the selection jumps to each character a little "too late", that is, after you have already crossed the position you want the selection to end at. You have to point to a character *after* the one you want to include. The current selection always is up to one character behind the cursor barline.  This results in a "sticky" feeling.

bug#47360: 27.1; using 'bar cursor, mouseclick is rounded to the wrong char position

[Eli Zaretskii]

> Date: Sat, 27 Mar 2021 17:53:41 +0000
> From: Julian Rohrhuber <rohrhuber@protonmail.com>
> Cc: Lars Ingebrigtsen <larsi@gnus.org>, Eli Zaretskii <eliz@gnu.org>, 47360@debbugs.gnu.org
> 
> There is one more case where one can feel the difference: when selecting with the mouse and dragging to the right, the selection jumps to each character a little "too late", that is, after you have already crossed the position you want the selection to end at. You have to point to a character *after* the one you want to include. The current selection always is up to one character behind the cursor barline.  This results in a "sticky" feeling.

Yes, selection in Emacs works on per-character granularity, because it
uses the faces infrastructure.  We'd need to do something very
different to make that use pixel granularity.  Patches are welcome.

bug#47360: 27.1; using 'bar cursor, mouseclick is rounded to the wrong char position

[Julian Rohrhuber via Bug reports for GNU Emacs, the Swiss army knife of text editors]

> On 27. Mar 2021, at 20:47, Eli Zaretskii <eliz@gnu.org> wrote:
>
>
>> Date: Sat, 27 Mar 2021 17:53:41 +0000
>> From: Julian Rohrhuber <rohrhuber@protonmail.com>
>> Cc: Lars Ingebrigtsen <larsi@gnus.org>, Eli Zaretskii <eliz@gnu.org>, 47360@debbugs.gnu.org
>>
>> There is one more case where one can feel the difference: when selecting with the mouse and dragging to the right, the selection jumps to each character a little "too late", that is, after you have already crossed the position you want the selection to end at. You have to point to a character *after* the one you want to include. The current selection always is up to one character behind the cursor barline.  This results in a "sticky" feeling.
>
> Yes, selection in Emacs works on per-character granularity, because it
> uses the faces infrastructure.  We'd need to do something very
> different to make that use pixel granularity.  Patches are welcome.

I don't think that a change of granularity would be necessarily at all to improve what I describe. All what would have to be done is to change at what *cursor* position the selection jumps to the next character (namely when it crosses its middle). So it would only another application of the solution to the current issue.

bug#47360: 27.1; using 'bar cursor, mouseclick is rounded to the wrong char position

[Eli Zaretskii]

> Date: Sun, 28 Mar 2021 07:15:38 +0000
> From: Julian Rohrhuber <rohrhuber@protonmail.com>
> Cc: larsi@gnus.org, 47360@debbugs.gnu.org
> 
> 
> >> There is one more case where one can feel the difference: when selecting with the mouse and dragging to the right, the selection jumps to each character a little "too late", that is, after you have already crossed the position you want the selection to end at. You have to point to a character *after* the one you want to include. The current selection always is up to one character behind the cursor barline.  This results in a "sticky" feeling.
> >
> > Yes, selection in Emacs works on per-character granularity, because it
> > uses the faces infrastructure.  We'd need to do something very
> > different to make that use pixel granularity.  Patches are welcome.
> 
> I don't think that a change of granularity would be necessarily at all to improve what I describe. All what would have to be done is to change at what *cursor* position the selection jumps to the next character (namely when it crosses its middle). So it would only another application of the solution to the current issue.

Sorry, I thought you were talking about the jumps, not about when the
jump is done.

However, with your proposal, the jump will be too early, so instead of
"lagging" the selection would sometimes "lead" the mouse pointer,
i.e. be ahead of it.  As long as the changes are one character at a
time, there's no way around that basic fact.

bug#47360: 27.1; using 'bar cursor, mouseclick is rounded to the wrong char position

[Julian Rohrhuber via Bug reports for GNU Emacs, the Swiss army knife of text editors]

> On 28. Mar 2021, at 09:25, Eli Zaretskii <eliz@gnu.org> wrote:
>
>>
>> Date: Sun, 28 Mar 2021 07:15:38 +0000
>> From: Julian Rohrhuber <rohrhuber@protonmail.com>
>> Cc: larsi@gnus.org, 47360@debbugs.gnu.org
>>
>>
>>>> There is one more case where one can feel the difference: when selecting with the mouse and dragging to the right, the selection jumps to each character a little "too late", that is, after you have already crossed the position you want the selection to end at. You have to point to a character *after* the one you want to include. The current selection always is up to one character behind the cursor barline.  This results in a "sticky" feeling.
>>>
>>> Yes, selection in Emacs works on per-character granularity, because it
>>> uses the faces infrastructure.  We'd need to do something very
>>> different to make that use pixel granularity.  Patches are welcome.
>>
>> I don't think that a change of granularity would be necessarily at all to improve what I describe. All what would have to be done is to change at what *cursor* position the selection jumps to the next character (namely when it crosses its middle). So it would only another application of the solution to the current issue.
>
> Sorry, I thought you were talking about the jumps, not about when the
> jump is done.
>
> However, with your proposal, the jump will be too early, so instead of
> "lagging" the selection would sometimes "lead" the mouse pointer,
> i.e. be ahead of it.  As long as the changes are one character at a
> time, there's no way around that basic fact.

Yes, it will still be off -- but only half as far. This makes a big difference in terms of interaction.
Checking other editors, they do it the same, and I think that is what is the "expected behaviour".