[Top][All Lists]

[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

From: Jan Djärv
Subject: Re: drag events should be defined as a movement to a different buffer position (Bug 9186)
Date: Sun, 21 Aug 2011 11:58:33 +0200
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:5.0) Gecko/20110624 Thunderbird/5.0

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.



reply via email to

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