[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
drag events should be defined as a movement to a different buffer positi
From: |
Andrew Schein |
Subject: |
drag events should be defined as a movement to a different buffer position (Bug 9186) |
Date: |
Fri, 19 Aug 2011 10:48:58 -0700 |
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 <address@hidden>
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
- drag events should be defined as a movement to a different buffer position (Bug 9186),
Andrew Schein <=