bug#6637: 24.0.50; kill ring being seriously polluted

[Tim Van Holder]

On 17 July 2010 19:53, David De La Harpe Golden <david@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.