drag events should be defined as a movement to a different buffer position (Bug 9186)

drag events should be defined as a movement to a different buffer position (Bug 9186)

[Andrew Schein]

https://lists.gnu.org/archive/html/bug-gnu-emacs/2011-08/msg00405.html

Back in 2001, the following revision defined the behavior of mouse
movements to cause a drag-copy to occur even when the position within
a buffer does not change:

revno: 40721
committer: Richard M. Stallman <rms@gnu.org>
timestamp: Mon 2001-11-05 04:19:56 +0000
message:
  (read_char): Use Fcar and Fcdr, not Fnth.
  (record_char): Likewise.

  (make_lispy_event): Don't insist a drag event must move to a different
  buffer position.  Instead, check for moving at least double_click_fuzz.

As a result, even clicking on the emacs window is enough to blow away
a pre-existing drag copy buffer if your hand moves even slightly...
making the pasting a drag-copy from a separate window a gamble.   This
is the case if you use your mouse to activate the emacs window instead
of alt-tab or some other mechanism.  Also, the current emacs behavior
is contrary to the user experience of other x-based applications such
as firefox.

Options for fixing this include reverting to a position-based rule or
else creating an emacs lisp variable that controls this behavior (as
exists for turning on/off drag copy altogether).  My patch takes the
former approach.

Cheers,

Andrew

-- 
Andrew I. Schein
www.andrewschein.com

Re: drag events should be defined as a movement to a different buffer position (Bug 9186)

[Jan Djärv]

Can you drag-copy one character with your change?

	Jan D.

Andrew Schein skrev 2011-08-19 19:48:
> https://lists.gnu.org/archive/html/bug-gnu-emacs/2011-08/msg00405.html
>
> Back in 2001, the following revision defined the behavior of mouse
> movements to cause a drag-copy to occur even when the position within
> a buffer does not change:
>
> revno: 40721
> committer: Richard M. Stallman<rms@gnu.org>
> timestamp: Mon 2001-11-05 04:19:56 +0000
> message:
>    (read_char): Use Fcar and Fcdr, not Fnth.
>    (record_char): Likewise.
>
>    (make_lispy_event): Don't insist a drag event must move to a different
>    buffer position.  Instead, check for moving at least double_click_fuzz.
>
> As a result, even clicking on the emacs window is enough to blow away
> a pre-existing drag copy buffer if your hand moves even slightly...
> making the pasting a drag-copy from a separate window a gamble.   This
> is the case if you use your mouse to activate the emacs window instead
> of alt-tab or some other mechanism.  Also, the current emacs behavior
> is contrary to the user experience of other x-based applications such
> as firefox.
>
> Options for fixing this include reverting to a position-based rule or
> else creating an emacs lisp variable that controls this behavior (as
> exists for turning on/off drag copy altogether).  My patch takes the
> former approach.
>
> Cheers,
>
> Andrew
>

Re: drag events should be defined as a movement to a different buffer position (Bug 9186)

[Andrew Schein]

Yes.

-Andrew

On Sun, Aug 21, 2011 at 2:58 AM, Jan Djärv <jan.h.d@swipnet.se> wrote:
> Can you drag-copy one character with your change?
>
>        Jan D.
>
> Andrew Schein skrev 2011-08-19 19:48:
>>
>> https://lists.gnu.org/archive/html/bug-gnu-emacs/2011-08/msg00405.html
>>
>> Back in 2001, the following revision defined the behavior of mouse
>> movements to cause a drag-copy to occur even when the position within
>> a buffer does not change:
>>
>> revno: 40721
>> committer: Richard M. Stallman<rms@gnu.org>
>> timestamp: Mon 2001-11-05 04:19:56 +0000
>> message:
>>   (read_char): Use Fcar and Fcdr, not Fnth.
>>   (record_char): Likewise.
>>
>>   (make_lispy_event): Don't insist a drag event must move to a different
>>   buffer position.  Instead, check for moving at least double_click_fuzz.
>>
>> As a result, even clicking on the emacs window is enough to blow away
>> a pre-existing drag copy buffer if your hand moves even slightly...
>> making the pasting a drag-copy from a separate window a gamble.   This
>> is the case if you use your mouse to activate the emacs window instead
>> of alt-tab or some other mechanism.  Also, the current emacs behavior
>> is contrary to the user experience of other x-based applications such
>> as firefox.
>>
>> Options for fixing this include reverting to a position-based rule or
>> else creating an emacs lisp variable that controls this behavior (as
>> exists for turning on/off drag copy altogether).  My patch takes the
>> former approach.
>>
>> Cheers,
>>
>> Andrew
>>
>



-- 
Andrew I. Schein
www.andrewschein.com