GNU bug report logs - #47360
27.1; using 'bar cursor, mouseclick is rounded to the wrong char position

Previous Next

Package: emacs;

Reported by: Julian Rohrhuber <rohrhuber <at> protonmail.com>

Date: Wed, 24 Mar 2021 12:52:01 UTC

Severity: normal

Found in version 27.1

Full log


Message #35 received at 47360 <at> debbugs.gnu.org (full text, mbox):

From: Julian Rohrhuber <rohrhuber <at> protonmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: larsi <at> gnus.org, 47360 <at> debbugs.gnu.org
Subject: Re: bug#47360: 27.1;
 using 'bar cursor, mouseclick is rounded to the wrong char position
Date: Sun, 28 Mar 2021 13:00:50 +0000

> On 28. Mar 2021, at 09:25, Eli Zaretskii <eliz <at> gnu.org> wrote:
>
>>
>> Date: Sun, 28 Mar 2021 07:15:38 +0000
>> From: Julian Rohrhuber <rohrhuber <at> protonmail.com>
>> Cc: larsi <at> gnus.org, 47360 <at> 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".







This bug report was last modified 4 years and 121 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.