bug#6637: 24.0.50; kill ring being seriously polluted

bug#6637: 24.0.50; kill ring being seriously polluted

[Tim Van Holder]

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.


In GNU Emacs 24.0.50.1 (i686-pc-linux-gnu, GTK+ Version 2.8.20)
 of 2010-07-15 on leeloo
Windowing system distributor `The Cygwin/X Project', version 11.0.10503000
configured using `configure  '--with-x''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: nil
  locale-coding-system: utf-8-unix
  default enable-multibyte-characters: t

Major mode: C/l

Minor modes in effect:
  show-paren-mode: t
  pc-selection-mode: t
  display-time-mode: t
  delete-selection-mode: t
  tooltip-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  size-indication-mode: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t
  abbrev-mode: t


Features:
(shadow sort mail-extr message sendmail rfc822 mml mml-sec mm-decode
mm-bodies mm-encode mail-parse rfc2231 rfc2047 rfc2045 ietf-drums
mailabbrev gmm-utils mailheader emacsbug multi-isearch parse-time vc-cvs
cc-mode cc-fonts easymenu cc-menus cc-cmds cc-styles cc-align cc-engine
cc-vars cc-defs dired regexp-opt package whitespace zastai jka-compr
uniquify advice help-fns advice-preload paren pc-select gnus gnus-ems
nnheader gnus-util mail-utils mm-util mail-prsvr wid-edit time delsel
cus-start cus-load tooltip ediff-hook vc-hooks lisp-float-type mwheel
x-win x-dnd tool-bar dnd fontset image fringe lisp-mode register page
menu-bar rfn-eshadow timer select scroll-bar mldrag mouse jit-lock
font-lock syntax facemenu font-core frame cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese hebrew
greek romanian slovak czech european ethiopic indian cyrillic chinese
case-table epa-hook jka-cmpr-hook help simple abbrev loaddefs button
minibuffer faces cus-face files text-properties overlay md5 base64
format env code-pages mule custom widget hashtable-print-readable
backquote make-network-process dbusbind dynamic-setting
system-font-setting font-render-setting gtk x-toolkit x multi-tty emacs)

bug#6637: 24.0.50; kill ring being seriously polluted

[David De La Harpe Golden]

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]

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 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 for one won't get to look properly at this until the weekend, though 
I'm not the only person about.

bug#6637: 24.0.50; kill ring being seriously polluted

[Thierry Volpiatto]

David De La Harpe Golden <david@harpegolden.net> writes:

> 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]
>
> 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 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 for one won't get to look properly at this until the weekend, though
> I'm not the only person about.

That appear even if delete-selection-mode is turned off, to disable that
i use here:

,----
| (setq x-select-enable-clipboard nil)
| (setq interprogram-paste-function nil)
`----

and it seem working fine.


-- 
Thierry Volpiatto
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

bug#6637: 24.0.50; kill ring being seriously polluted

[Tim Van Holder]

On 15 July 2010 11:55, David De La Harpe Golden <david@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.

bug#6637: 24.0.50; kill ring being seriously polluted

[Chong Yidong]

Tim Van Holder <tim.vanholder@gmail.com> writes:

> 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.

Your description is too vague.  Please provide a precise, step-by-step
recipe for the problem, starting with `emacs -Q'.

bug#6637: 24.0.50; kill ring being seriously polluted

[Tim Van Holder]

On 15 July 2010 16:03, Chong Yidong <cyd@stupidchicken.com> wrote:
> Tim Van Holder <tim.vanholder@gmail.com> writes:
>
>> 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.
>
> Your description is too vague.  Please provide a precise, step-by-step
> recipe for the problem, starting with `emacs -Q'.

Fair enough.

1) emacs -Q

Note: this is run from an SSH shell (putty) connected to a Debian box
with X forwarding using Cygwin's X server on my local PC.
This shows the normal *scratch* buffer with 3 comment lines at the top
and point below them.

2) Holding the shift key, press the up arrow until you're at the top
of the buffer

This selects the comment lines and the line below it.

3) Release the shift key and press the down arrow until you're back at
the bottom of the buffer

4) Press C-y

This yanks in the comment lines, even though I at no point requested a
kill or copy-as-kill. I don't remember this ever being the case in the
past.
In addition, with today's BZR head the yank takes a very long time
(4-5 seconds); the mouse cursor even switches to its "please wait"
form. This long wait goes away when I set x-select-clipboard-enable to
false.

bug#6637: 24.0.50; kill ring being seriously polluted

[Chong Yidong]

Tim Van Holder <tim.vanholder@gmail.com> writes:

> 1) emacs -Q
> 2) Holding the shift key, press the up arrow until you're at the top
> of the buffer
> 3) Release the shift key and press the down arrow until you're back at
> the bottom of the buffer
> 4) Press C-y
>
> This yanks in the comment lines, even though I at no point requested a
> kill or copy-as-kill.

Go to any X application (firefox, etc) with a text field.
Holding shift, press the arrow keys and select some text.
Release shift, and press another down arrow to deselect it.

In Emacs 23 (in the absence of latest changes):

Run `emacs -Q'.
C-y

The text you selected is yanked into the buffer.  This is because the
other X application put your selected text in the primary selection.
How is the behavior of Emacs' new shift selection different from the
other X application's shift selection?

bug#6637: 24.0.50; kill ring being seriously polluted

[Tim Van Holder]

On 16 July 2010 17:57, Chong Yidong <cyd@stupidchicken.com> wrote:
> Tim Van Holder <tim.vanholder@gmail.com> writes:
>
>> 1) emacs -Q
>> 2) Holding the shift key, press the up arrow until you're at the top
>> of the buffer
>> 3) Release the shift key and press the down arrow until you're back at
>> the bottom of the buffer
>> 4) Press C-y
>>
>> This yanks in the comment lines, even though I at no point requested a
>> kill or copy-as-kill.
>
> Go to any X application (firefox, etc) with a text field.
> Holding shift, press the arrow keys and select some text.
> Release shift, and press another down arrow to deselect it.
>
> In Emacs 23 (in the absence of latest changes):
>
> Run `emacs -Q'.
> C-y
>
> The text you selected is yanked into the buffer.  This is because the
> other X application put your selected text in the primary selection.
> How is the behavior of Emacs' new shift selection different from the
> other X application's shift selection?

I generally spend all my time in Emacs, so I don't know/care very much
about the behaviour of other X applications (especially with the way
I'm running Emacs these days, it tends to be the only X app running).
All I know is I have been selecting text in Emacs for a long time and
it has never appeared in the kill ring (maybe because of
pc-selection-mode, I don't know).
I do expect to be able to yank text copied from other applications,
and I do expect to be able to paste stuff elsewhere that I've
copied/killed in Emacs; and this has so far always been the case.

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).

Look, if most people are happy with the new behaviour then fine, make
it the default. But I'd still want a customizable option to disable it
(or for it to be automatically disabled when pc-selection-mode is
active).
Given that there is a pc-selection-mode, perhaps this new behaviour
could be made an x-selection-mode, giving people the choice of which
behaviour they want.

bug#6637: 24.0.50; kill ring being seriously polluted

[Chong Yidong]

Tim Van Holder <tim.vanholder@gmail.com> writes:

> 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).

Your description is too vague.  Please provide a step by step recipe
demonstrating the problem, starting with `emacs -Q'.

bug#6637: 24.0.50; kill ring being seriously polluted

[David De La Harpe Golden]

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).

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.

bug#6637: 24.0.50; kill ring being seriously polluted

[David De La Harpe Golden]

On 19/07/10 09:22, Tim Van Holder wrote:

> 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.

Ah, good. :-).  Though we probably need to keep an eye open for Cygwin/X 
specific interaction problems.

> 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.

Yes, just checked - Both Emacs 22 and 23 merrily do that (to the 
clipboard if set to use the clipboard in the first place). However it 
may have been less noticeable than it has become since the recent 
changes, said recent changes including using the clipboard in more 
situations than before on some platforms.

It is likely possible to do something about it in future, it's a similar 
problem to some other zero-length-region problems that are known to be 
addressable.

bug#6637: 24.0.50; kill ring being seriously polluted

[Angelo Graziosi]

Chong Yidong wrote:
> Tim Van Holder <address@hidden> writes:
>
>> 1) emacs -Q
>> 2) Holding the shift key, press the up arrow until you're at the top
>> of the buffer
>> 3) Release the shift key and press the down arrow until you're back at
>> the bottom of the buffer
>> 4) Press C-y
>>
>> This yanks in the comment lines, even though I at no point requested a
>> kill or copy-as-kill.
>
> Go to any X application (firefox, etc) with a text field.
> Holding shift, press the arrow keys and select some text.
> Release shift, and press another down arrow to deselect it.
>
> In Emacs 23 (in the absence of latest changes):

Emacs 23 or 24?

>
> Run `emacs -Q'.
> C-y
>
> The text you selected is yanked into the buffer.  This is because the

I have done *exactly* what you suggest on Kubuntu 10.04, with GTK build 
of Emacs24 trunk rev.100832: it DOS NOT paste the selected text but 
garbage (something in the clipboard form previous selections...)

Since this announcement [*], Copy/Pasting does not seem working right :(.

Ciao,
Angelo.

---
[*] http://lists.gnu.org/archive/html/emacs-devel/2010-07/msg00720.html

> other X application put your selected text in the primary selection.
> How is the behavior of Emacs' new shift selection different from the
> other X application's shift selection?

bug#6637: 24.0.50; kill ring being seriously polluted

[Chong Yidong]

Angelo Graziosi <angelo.graziosi@alice.it> writes:

>> Go to any X application (firefox, etc) with a text field.
>> Holding shift, press the arrow keys and select some text.
>> Release shift, and press another down arrow to deselect it.
>>
>> In Emacs 23 (in the absence of latest changes):
>> Run `emacs -Q'.
>> C-y
>>
>> The text you selected is yanked into the buffer.  This is because the
>
> I have done *exactly* what you suggest on Kubuntu 10.04, with GTK
> build of Emacs24 trunk rev.100832: it DOS NOT paste the selected text
> but garbage (something in the clipboard form previous selections...)

I tested the recipe a vanilla build of Emacs 23.2 from the tarball, with
`emacs -Q'; the selected text is indeed pasted.

However, it seems that the behavior of Firefox differs from that of
Gedit and Openoffice; those disown the selection after deselection.
Perhaps the behavior of Firefox is aberrant.  Assuming the latter is
more standard, I will look into changing Emacs' behavior to follow it.

bug#6637: 24.0.50; kill ring being seriously polluted

[Angelo Graziosi]

Il 17/07/2010 4.37, Chong Yidong ha scritto:
> Angelo Graziosi<angelo.graziosi@alice.it>  writes:
>
>>> Go to any X application (firefox, etc) with a text field.
>>> Holding shift, press the arrow keys and select some text.
>>> Release shift, and press another down arrow to deselect it.
>>>
>>> In Emacs 23 (in the absence of latest changes):
>>> Run `emacs -Q'.
>>> C-y
>>>
>>> The text you selected is yanked into the buffer.  This is because the
>>
>> I have done *exactly* what you suggest on Kubuntu 10.04, with GTK
>> build of Emacs24 trunk rev.100832: it DOS NOT paste the selected text
>> but garbage (something in the clipboard form previous selections...)
>
> I tested the recipe a vanilla build of Emacs 23.2 from the tarball, with
> `emacs -Q'; the selected text is indeed pasted.

I do not doubt it works with Emacs 23! The problems start after this [*] :(.

> However, it seems that the behavior of Firefox differs from that of
> Gedit and Openoffice; those disown the selection after deselection.
> Perhaps the behavior of Firefox is aberrant.  Assuming the latter is
> more standard, I will look into changing Emacs' behavior to follow it.

Really I tested not only with FF but also with Konqueror: same results.

Anyway, other problems occur, say with rev. >= 100832 (but perhaps also 
with prev.):

emacs -Q &

Now double clicking on the text of scratch buffer freezes Emacs and the 
blinking cursor disappears. Only clicking on the menu bar items, and 
then in the scratch buffer, revert the freeze.

Ciao,
Angelo.

---
[*] http://lists.gnu.org/archive/html/emacs-devel/2010-07/msg00720.html