GNU bug report logs -
#6956
24.0.50; pasting mouse selection in other session pastes only first word
Previous Next
Reported by: "Drew Adams" <drew.adams <at> oracle.com>
Date: Tue, 31 Aug 2010 16:48:02 UTC
Severity: normal
Found in version 24.0.50
Done: Eli Zaretskii <eliz <at> gnu.org>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
On 05/09/10 02:53, Chong Yidong wrote:
> We don't need to explain what mouse-drag-copy-region does twice.
> Just add a separate paragraph saying
>
> If `mouse-drag-copy-region' is non-nil, this command also saves the
> region to the kill ring, replacing the previous kill if it was also
> made with `mouse-save-then-kill'.
>
^^^ Strictly that's not true, it also replaces kills made by mouse-drag
i.e. an already active region (otherwise you would drag select a region
with mouse-1, then mouse-3 extend, and you'd get two kill ring entries).
Here's one with revised doc phrasing.
...I haven't tried making shift-selection respect
"mouse"-"drag"-copy-region as yet, but that should be straightforward
given similarity to the "select-active-regions => 'only" code path.
(It's not like I'm personally going to use mouse-drag-copy-region => t
in any case....)
The customization name would then be kind of misleading, but, well, it
has company. Effectively, mouse-drag-copy-region would "really" be
something like the (hypothetical) "clipboard-active-regions => 'only" in
end effect, though probably implemented by hitting the kill ring and
thus (maybe) the os clipboard as a side effect, so maybe
"killring-active-regions => 'only" would be more accurate.
[mouse-save-then-kill-save-on-mdcr_r2.diff (text/x-patch, attachment)]
This bug report was last modified 14 years and 329 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.