GNU bug report logs -
#6637
24.0.50; kill ring being seriously polluted
Previous Next
Full log
Message #14 received at 6637 <at> debbugs.gnu.org (full text, mbox):
On 15 July 2010 11:55, David De La Harpe Golden <david <at> harpegolden.net> wrote:
> On 15/07/10 09:50, Tim Van Holder wrote:
>>
>> With the current BZR head, the kill ring seems to be seriously
>> broken, at least in conjunction with pc-selection-mode.
>> It seems that whenever I mark a region (using shift + arrow keys), the
>> contents of that region go into the kill ring, and when I enter text to
>> replace that region, the first character (and only the first character)
>> goes into the kill ring.
>> This seriously breaks some common activities, i.e. copying a piece of
>> code, then pasting it several times, adjusting those parts that need
>> adjusting.
>> Is there an option to disable this less-than-desirable "functionality"
>> until the behaviour is returned to sanity? If not, I suppose I can
>> handle a few extra M-y presses for a while, but I'd like to see this
>> fixed as soon as possible.
>>
>
> [Well, please bear in mind you're running unstable development code if
> you're running bzr head rather than a release AFAIU]
Yeah I know - but I've been using emacs' CVS HEAD for years and there
have rarely been cases where there was anything obviously broken (and
with no immediately obvious workaround), so I guess I've been spoilt
:-D.
> If you just want shift-arrow selection, note that that has worked in emacs
> anyway for a while, without pc-selection-mode turned on as such.
> But since your bug was for the delete-selection part, well, I guess that's
> less than satisfactory.
The bug is also for the key-based selection ending up in the kill
ring. I don't think that has ever been the case before.
Like I said, I routinely copy/yank stuff and then adjust parts as
needed (usually relying both on S-arrow selection and delete-selection
behaviour for these adjustments) and this is the first time I've
noticed it affecting the next yank. In fact, there have also been many
cases where I selected things for the express purpose of replacing
them via a yank.
> The problem is likely in delete-selection-mode (which pc-selection-mode uses
> underneath) or some of the code it calls in simple.el:
>
> I was totally expecting this to be related to certain recent changes in
> default selection handling, but breakage happened in my short test even with
> them turned off on X11 emacs on debian. It may/must still be related to
> recent rearrangements, of course, just perhaps not in the area I thought.
I think the root problem is going to be the issue above (S-arrow
selection ending up in kill ring). That the initial region replacement
done by delete-selection ends up in the kill ring is probably a side
effect.
> I for one won't get to look properly at this until the weekend, though I'm
> not the only person about.
I just looked at the emacs-devel archives and it looks like there were
some recent changes relating to integrating emacs' kill ring with the
X clipboard; my guess is that the issue I'm seeing is related to that.
Customizing x-select-enable-clipboard made no difference though.
This bug report was last modified 12 years and 292 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.