bug-gnu-emacs
[Top][All Lists]
Advanced

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

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


From: Julian Rohrhuber
Subject: bug#47360: 27.1; using 'bar cursor, mouseclick is rounded to the wrong char position
Date: Sun, 28 Mar 2021 13:13:20 +0000


> On 28. Mar 2021, at 15:00, Julian Rohrhuber <rohrhuber@protonmail.com> wrote:
>
>> 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".

here are screen recordings for both (each with emacs and atom), I hope they 
show the issue better than I can do with words:



Attachment: cursor-rounding-emacs.mov
Description: QuickTime movie

Attachment: cursor-rounding-atom.mov
Description: QuickTime movie

Attachment: selection-rounding-emacs.mov
Description: QuickTime movie

Attachment: selection-rounding-atom.mov
Description: QuickTime movie


reply via email to

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