[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: drag events should be defined as a movement to a different buffer po
Re: drag events should be defined as a movement to a different buffer position (Bug 9186)
Mon, 22 Aug 2011 09:24:26 -0700
On Sun, Aug 21, 2011 at 2:58 AM, Jan Djärv <address@hidden> wrote:
> Can you drag-copy one character with your change?
> Jan D.
> Andrew Schein skrev 2011-08-19 19:48:
>> 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<address@hidden>
>> timestamp: Mon 2001-11-05 04:19:56 +0000
>> (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.
Andrew I. Schein