GNU bug report logs -
#6637
24.0.50; kill ring being seriously polluted
Previous Next
Full log
View this message in rfc822 format
On 17 July 2010 19:53, David De La Harpe Golden <david <at> harpegolden.net> wrote:
> On 17/07/10 16:32, Tim Van Holder wrote:
>
>
>> The following is something I do a lot as part of code editing:
>> 1) copy/kill something
>> 2) yank the copied/kill text
>> 3) select certain portions and replace them as needed for that copy
>> 4) go back to step 2) if needed
>> The new behaviour interferes with this (and I don't see how it can do
>> anything but interfere when pc-selection-mode is active).
>>
>
> Firstly (and this may be premature to mention (sorry) given there are more
> known unresolved issues) but N.B. there have been some even more recent
> changes addressing some problems with the recent changes, please try
> starting from emacs -Q with an emacs trunk build >= rev. 100838 and see if
> the problems you are having persist. Unfortunately, there are known issues
> even in that revision, but they will (probably) be more subtle. There is
> effort ongoing to address them.
>
> But as Chong just said, that's too vague to reproduce an issue from.
>
> I do realise it's a drag to write concrete steps out in the detail really
> required - but it's pretty necessary for adequate repeatability, in this
> area small details matter.
>
> Ideally (and I acknowledge it is time consuming), you would start from emacs
> -Q with a known test string (say the initial ";; This buffer is for..." or
> "The quick brown fox jumps over the lazy dog."), and describe the keystrokes
> and mouse clicks and point and mouse movements right down to which letters
> the point and mouse are on, the results of the operations, and the results
> you expected if they vary.
>
> It is also possible there are Cygwin/X specific issues that you are seeing
> but the rest of us on other X servers aren't. Eyeing its changelog (I
> personally don't have access to a windows box to test on), it likely has
> somewhat hairy handling of integration with the w32 clipboard. OTOH, said
> handling appears to be expecting now-conventional X11 app selection
> interaction behaviour, so making emacs adopt that behaviour by default
> shouldn't cause any gross problems (though will inevitably be somewhat
> different to emacs' historical default behaviour).
I set out to do just that (intending to duplicate the *scratch*
comment, replacing "Lisp" by a few other language names), but the
current (r100846) behaviour seems to match with my expected/desired
behaviour again. Arrow-selection does not affect the kill ring, nor
does typing-to-replace-the-region cause the first such typed letter to
be added to the kill ring.
The only thing I see is that emacs is perfectly happy to copy/kill the
empty string: arrow-selecting an empty region and hitting C-insert
(copy-region-as-kill in pc-selection-mode) make subsequent yanks
insert nothing. It's perfectly possible that emacs has always done so
- I'm only mentioning it because I notice it now.
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.