Saving the selection before killing (was: Selection not to be copied into kill-ring)

Saving the selection before killing (was: Selection not to be copied into kill-ring)

[Stefan Monnier]

The following message is a courtesy copy of an article
that has been posted to gnu.emacs.help as well.

>>>>> "Eli" == Eli Zaretskii <eliz@gnu.org> writes:
>> From: Will <schimpanski@gmx.de>
>> Newsgroups: gnu.emacs.help
>> Date: Thu, 12 Jul 2007 14:14:01 +0200
>> 
>> I'd like to copy text from external applications (e.g. web browser) to 
>> an Emacs buffer. Often before I paste the text into an Emacs buffer I'd 
>> like to delete text in the this buffer _without_ it being copied to the 
>> kill-ring, because then the text from the external application gets lost.
>> 
>> => How do I switch off that hightlighted text is copied automatially 
>> into the kill-ring?
>> => How do I delete a region without it getting copied into the 
>> kill-ring, e.g. by highlighting the text and pressing <delete>?

> Try "M-x delete-selection-mode RET".  Is this what you want?

I bump into the OP's problem every once in a while, but I don't like
delete-selection-mode for some reason, so I use the patch below instead.
What it does is that when you kill text, before doing the kill (which will
replace the current X-selection with the killed text), we save the current
selection on the kill-ring (only if it doesn't come from us, of course
since otherwise it's already in the kill-ring).  So I can simply do my kill
and then C-y (which re-inserts what I just killed) and M-y (which replaces
the text with the previous X-selection).

This feature is pretty unnoticeable, so I'm tempted to install it just like
that, but maybe people want yet-another-config-var to control it?


        Stefan


--- orig/lisp/simple.el
+++ mod/lisp/simple.el
@@ -2479,6 +2536,20 @@
 argument is not used by `insert-for-yank'.  However, since Lisp code
 may access and use elements from the kill ring directly, the STRING
 argument should still be a \"useful\" string for such uses."
+  ;; To better pretend that X-selection = head-of-kill-ring, we copy other
+  ;; application's X-selection to the kill-ring.  This comes in handy when
+  ;; you do something like:
+  ;; - copy a piece of text in your web-browser.
+  ;; - have to do some editing (including killing) before you can yank
+  ;;   that text.
+  ;; Note: this piece of code inspired from current-kill.
+  (let ((paste (and interprogram-paste-function
+                    (funcall interprogram-paste-function))))
+    (when paste
+      (let ((interprogram-cut-function nil)
+            (interprogram-paste-function nil))
+        (kill-new paste))))
+  ;; The actual kill-new functionality.
   (if (> (length string) 0)
       (if yank-handler
 	  (put-text-property 0 (length string)

Re: Saving the selection before killing

[David Kastrup]

The following message is a courtesy copy of an article
that has been posted to gnu.emacs.help as well.

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> From: Will <schimpanski@gmx.de>
>>> Newsgroups: gnu.emacs.help
>>> Date: Thu, 12 Jul 2007 14:14:01 +0200
>>> 
>>> I'd like to copy text from external applications (e.g. web
>>> browser) to an Emacs buffer. Often before I paste the text into an
>>> Emacs buffer I'd like to delete text in the this buffer _without_
>>> it being copied to the kill-ring, because then the text from the
>>> external application gets lost.
>
> I bump into the OP's problem every once in a while, but I don't like
> delete-selection-mode for some reason, so I use the patch below
> instead.  What it does is that when you kill text, before doing the
> kill (which will replace the current X-selection with the killed
> text), we save the current selection on the kill-ring (only if it
> doesn't come from us, of course since otherwise it's already in the
> kill-ring).  So I can simply do my kill and then C-y (which
> re-inserts what I just killed) and M-y (which replaces the text with
> the previous X-selection).
>
> This feature is pretty unnoticeable, so I'm tempted to install it
> just like that, but maybe people want yet-another-config-var to
> control it?

The problem I see is that it is pretty unnoticeable iff the size of
the selection is small compared to the network bandwidth.  It would be
nicest if Emacs could tell the X server "if someone asks for a
selection, tell me, and then I'll tell you whether I'll hand over a
selection, or whether you can ask the one who has it now for it."

I don't know the X protocols to know whether this is feasible with
regard to the network traffic.  It might be infeasible due to
program's expectations about the kill ring, anyway.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Saving the selection before killing (was: Selection not to be copied into kill-ring)

[Richard Stallman]

    What it does is that when you kill text, before doing the kill (which will
    replace the current X-selection with the killed text), we save the current
    selection on the kill-ring (only if it doesn't come from us, of course
    since otherwise it's already in the kill-ring).

When this is what you want, it's useful.  The only possible drawback
could be that it operates when you don't want it to.  It would
spuriously insert into the kill ring whenever you kill something Emacs
and there is an X selection in another program which you did not
intend to pull into Emacs.

Are we sure that won't happen and annoy people?

Re: Saving the selection before killing

[Stefan Monnier]

>     What it does is that when you kill text, before doing the kill (which will
>     replace the current X-selection with the killed text), we save the current
>     selection on the kill-ring (only if it doesn't come from us, of course
>     since otherwise it's already in the kill-ring).

> When this is what you want, it's useful.  The only possible drawback
> could be that it operates when you don't want it to.  It would
> spuriously insert into the kill ring whenever you kill something Emacs
> and there is an X selection in another program which you did not
> intend to pull into Emacs.

> Are we sure that won't happen and annoy people?

Well, I'm sure sure it does happen since the code does it blindly.
The question is whether it makes a difference to the user.  What you have to
keep in mind is that it inserts the text as the "last but one" element, so
just C-y is not affected, it's only the subsequent M-y which is changed.
So the only case which may cause problem is when the user wanted to do C-y
followed by N times M-y where she'd then need to use M-y N+1 times.


        Stefan

Re: Saving the selection before killing

[Richard Stallman]

      What you have to
    keep in mind is that it inserts the text as the "last but one" element, so
    just C-y is not affected, it's only the subsequent M-y which is changed.
    So the only case which may cause problem is when the user wanted to do C-y
    followed by N times M-y where she'd then need to use M-y N+1 times.

Yes -- but that could still potentially annoy.

I think it would be useful for people to try this out and report on
how often it is useful, and whether it surprises them.

Re: Saving the selection before killing

[Juri Linkov]

>       What you have to
>     keep in mind is that it inserts the text as the "last but one" element, so
>     just C-y is not affected, it's only the subsequent M-y which is changed.
>     So the only case which may cause problem is when the user wanted to do C-y
>     followed by N times M-y where she'd then need to use M-y N+1 times.
>
> Yes -- but that could still potentially annoy.
>
> I think it would be useful for people to try this out and report on
> how often it is useful, and whether it surprises them.

I like this patch very much.  That is what I needed for many years.
But I think asking people to try it out will not result in many responses.
People who like it will start using it silently, and people who don't like
probably will not try it.  The only way to get more opinions is to install it
and wait for a reaction.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Saving the selection before killing

[Richard Stallman]

    But I think asking people to try it out will not result in many responses.
    People who like it will start using it silently, and people who don't like
    probably will not try it.  The only way to get more opinions is to install it
    and wait for a reaction.

I think people on this list will tell us what they think of it.
Would people please try installing it and report what they think?

Re: Saving the selection before killing

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     But I think asking people to try it out will not result in many
>     responses.  People who like it will start using it silently, and
>     people who don't like probably will not try it.  The only way to
>     get more opinions is to install it and wait for a reaction.
>
> I think people on this list will tell us what they think of it.
> Would people please try installing it and report what they think?

The main problem I saw with it was working over non-local X
connections where it could lead to annoying and inexplicable
slowdowns.

That is not the normal use case, but it is a situation where being
able to still work with Emacs would be important.  I remember that
there has been a _lot_ of people complaining about inexplicable
slowdowns on the XEmacs developer list, and the general advice was to
disable some hooks that provided a similarly "sensible" default
behavior with respect to possibly unrelated selections.

I don't know the details, though, but it probably was the somewhat
different case of every Emacs kill command copying stuff to the
clipboard or so (or some clipboard application milking a selection
whenever one was available).

Anyway, the point is that this was also not detected as a problem in
testing, and still caused frequent annoyance for people with not too
unusual X setups.  So I'd be careful of milking selections by default.
Maybe one reasonable test case would be two Emacs sessions side by
side.  Oh, by the way: does Emacs see its own selections?

-- 
David Kastrup

Re: Saving the selection before killing

[Richard Stallman]

    The main problem I saw with it was working over non-local X
    connections where it could lead to annoying and inexplicable
    slowdowns.

Is that an observation or a theoretical conclusion?
The question is how much slowdown this feature adds
when there is no selection.  How long does it take
to determine that there is no selection?

Re: Saving the selection before killing

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     The main problem I saw with it was working over non-local X
>     connections where it could lead to annoying and inexplicable
>     slowdowns.
>
> Is that an observation or a theoretical conclusion?

That's what people frequently were complaining about on the XEmacs
lists, and I am not really sure we did not also have a time with
similar complaints.  Now that was, unless I am mistaken, for large
selections _from_ Emacs that were picked up elsewhere (like
mark-whole-buffer would do), whereas the case we are debating is Emacs
picking up selections from outside, and maybe megabyte selections are
less common outside than inside.

But if one is running more than one Emacs instance (and I don't know
under which circumstances Emacs might offer _itself_ a selection),
then we _have_ the same porential for large selections flying around.

> The question is how much slowdown this feature adds when there is no
> selection.

Uh, why?  Can we rule out that there are large selections?

> How long does it take to determine that there is no selection?

That should be reasonably fast.  I would expect noticeable effects at
most when running keyboard macros.  However, keyboard macros that yank
stuff are not really infrequent, and when one is running them on a
whole buffer, checking the display remotely every time _might_
conceivably make a difference.  In contrast to the above observation,
this is, for now, a theoretical conclusion.

This theoretical conclusion also means that if you go elsewhere while
your keyboard macro runs and mark some text with the mouse, the
keyboard macro will suddenly do something different.

Perhaps we should ignore selections altogether when executing keyboard
macros, not just in this case.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Saving the selection before killing

[Jan Djärv]

David Kastrup skrev:

> 
> But if one is running more than one Emacs instance (and I don't know
> under which circumstances Emacs might offer _itself_ a selection),
> then we _have_ the same porential for large selections flying around.
> 

If Emacs requests the selection it does not know that the program offering the 
selection is another instance of Emacs.  So different instances of Emacs 
behaves just like one instance of Emacs and several X programs w.r.t. selections.

>> The question is how much slowdown this feature adds when there is no
>> selection.
> 
> Uh, why?  Can we rule out that there are large selections?

Oh, no we can't and should not.

	Jan D.

Re: Saving the selection before killing

[Richard Stallman]

    > The question is how much slowdown this feature adds when there is no
    > selection.

    Uh, why?  

Because (1) usually there is no selection, and (2) when there is a
selection, that means you want this feature to do something useful
for you.

	      Can we rule out that there are large selections?

If we install this feature, it means we call on users to make sure to
have selections in other programs, when they kill in Emacs, only when
they want to pull those selections into Emacs.

    That should be reasonably fast.  I would expect noticeable effects at
    most when running keyboard macros.  However, keyboard macros that yank
    stuff are not really infrequent, and when one is running them on a
    whole buffer, checking the display remotely every time _might_
    conceivably make a difference.

Maybe this feature should be disabled inside keyboard macros.

    Perhaps we should ignore selections altogether when executing keyboard
    macros, not just in this case.

Perhaps.  I won't say outright that that's a bad idea.  But it is a
separate question.

Re: Saving the selection before killing

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     > The question is how much slowdown this feature adds when there is no
>     > selection.
>
>     Uh, why?  
>
> Because (1) usually there is no selection,

I don't find it uncommon to have one.  Indeed, with Emacs' transient
mark mode (which is part of a lot of user convenience settings), one
has a selection quite often without particular purpose.

> and (2) when there is a selection, that means you want this feature
> to do something useful for you.

See above.

> 	      Can we rule out that there are large selections?
>
> If we install this feature, it means we call on users to make sure to
> have selections in other programs, when they kill in Emacs, only when
> they want to pull those selections into Emacs.

Given that Emacs itself pretty lusciously waves selections around when
transient-mark-mode is enabled, that sounds like a rather heavy
request which Emacs itself does not heed.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Saving the selection before killing

[Jan Djärv]

Richard Stallman skrev:
>     The main problem I saw with it was working over non-local X
>     connections where it could lead to annoying and inexplicable
>     slowdowns.
> 
> Is that an observation or a theoretical conclusion?
> The question is how much slowdown this feature adds
> when there is no selection.  How long does it take
> to determine that there is no selection?

The time it takes to send a request to the X server and get a reply.  But for 
a "normal" X session, you almost always have a selection somewhere.

	Jan D.

Re: Saving the selection before killing

[Jan Djärv]

David Kastrup skrev:

> I don't know the details, though, but it probably was the somewhat
> different case of every Emacs kill command copying stuff to the
> clipboard or so (or some clipboard application milking a selection
> whenever one was available).

Search for klipper in etc/PROBLEMS.  Now this proposal will make Emacs behave 
like a buggy klipper.  Requesting the selection "just for the fun of it" is 
not something Emacs should do.  If the selection in large, Emacs will be slow 
and unresponsive.  The selection may be data Emacs can't handle anyway, such 
as audio data.  If someone makes a big selection in OpenOffice for example, 
Emacs will get the text version of the selection, which in itself is not 
useful, all formatting is lost.  I'd be annoyes to see that in my kill ring.

Please just request selection when the user asks for it.

	Jan D.

Re: Saving the selection before killing

[Stefan Monnier]

> Search for klipper in etc/PROBLEMS.  Now this proposal will make Emacs
> behave like a buggy klipper.

Not at all.  The bug in the klipper was that it requested the selection over
and over.  My code only causes the selection to be requested when it shifts
from being owned by some other app to being owned by Emacs.  I.e. there's no
looping involved.

> I'd be annoyes to see that in my kill ring.

Please try it before jumping to conclusions.


        Stefan

Re: Saving the selection before killing

[Jan Djärv]

Stefan Monnier skrev:
>> Search for klipper in etc/PROBLEMS.  Now this proposal will make Emacs
>> behave like a buggy klipper.
> 
> Not at all.  The bug in the klipper was that it requested the selection over
> and over.  My code only causes the selection to be requested when it shifts
> from being owned by some other app to being owned by Emacs.  I.e. there's no
> looping involved.

Looping was only part of the problem.  Large selection was also a factor.  If
Emacs will request large selections from other programs, they can become
sluggish too.  In the common case this is not a problem as selection usually
are small, i.e. a couple of lines.

> 
>> I'd be annoyes to see that in my kill ring.
> 
> Please try it before jumping to conclusions.
> 

I did try it.  Open up an OO document with some pages, select all text in the
document.  Move to Emacs, kill some text, C-y, M-y

I get the OO document pasted as a big chunk of text.  Pasting the selection
from other applications into Emacs (or any other application) over a slow link
is already a problem.  This would make it worse.

	Jan D.

Re: Saving the selection before killing

[Stefan Monnier]

>>> Search for klipper in etc/PROBLEMS.  Now this proposal will make Emacs
>>> behave like a buggy klipper.
>> Not at all.  The bug in the klipper was that it requested the selection
>> over and over.  My code only causes the selection to be requested when it
>> shifts from being owned by some other app to being owned by Emacs.
>> I.e. there's no looping involved.

> Looping was only part of the problem.  Large selection was also a factor.

I see no evidence that someone would have noticed something if it
weren't looping.

> If Emacs will request large selections from other programs, they can
> become sluggish too.

They'll be temporarily busy replying to Emacs just at those moments when you
do a kill in Emacs (not all kills, of course).  That is a far cry from
"become sluggish".

>>> I'd be annoyed to see that in my kill ring.
>> Please try it before jumping to conclusions.

> I did try it.  Open up an OO document with some pages, select all text in
> the document.  Move to Emacs, kill some text, C-y, M-y.  I get the OO
> document pasted as a big chunk of text.

Yes, that's the expected behavior.  Which part is *annoying*?
Another M-y will get you to the next kill-ring element.
The same thing could have happened without my patch if you happened to have
killed a big chunk of text in the past.

> Pasting the selection from other applications into Emacs (or any other
> application) over a slow link is already a problem.  This would make
> it worse.

That could be.  AFAIK, this is the only serious objection you have.


        Stefan


PS: You don't need a slow link: just take a local application, select
something in it, then suspend it, then go to Emacs and try to do C-y (or
C-k with my patch).

Re: Saving the selection before killing

[Jan Djärv]

Stefan Monnier skrev:
>>>> Search for klipper in etc/PROBLEMS.  Now this proposal will make Emacs
>>>> behave like a buggy klipper.
>>> Not at all.  The bug in the klipper was that it requested the selection
>>> over and over.  My code only causes the selection to be requested when it
>>> shifts from being owned by some other app to being owned by Emacs.
>>> I.e. there's no looping involved.
> 
>> Looping was only part of the problem.  Large selection was also a factor.
> 
> I see no evidence that someone would have noticed something if it
> weren't looping.
> 

You obviously haven't run Emacs over a slow (well say less than 1 Mbit/s) ssh 
forward X connection.

>> If Emacs will request large selections from other programs, they can
>> become sluggish too.
> 
> They'll be temporarily busy replying to Emacs just at those moments when you
> do a kill in Emacs (not all kills, of course).  That is a far cry from
> "become sluggish".

Selections over slow links are painful right now.  Emacs 22 is so much slower 
in this regard than 21.x.  For example, single click with mouse-1 sometimes 
makes Emacs loop forever (C-g works though), redisplay for small changes can 
take 10:s of seconds, popup of tool tip also takes several seconds.  Your 
proposal should be customizable, and preferrably default off, as it is a new 
behaviour.

> 
>>>> I'd be annoyed to see that in my kill ring.
>>> Please try it before jumping to conclusions.
> 
>> I did try it.  Open up an OO document with some pages, select all text in
>> the document.  Move to Emacs, kill some text, C-y, M-y.  I get the OO
>> document pasted as a big chunk of text.
> 
> Yes, that's the expected behavior.  Which part is *annoying*?

That when that amount of text gets drawn over a slow link it takes time.  And 
that when Emacs redisplays, it takes time.  We are talking 10:s of seconds here.

> Another M-y will get you to the next kill-ring element.

Yes, but I have to wait several seconds before Emacs is responsive again.

> The same thing could have happened without my patch if you happened to have
> killed a big chunk of text in the past.

But then I would know it was in the kill ring.

	Jan D.

Re: Saving the selection before killing

[Stefan Monnier]

> You obviously haven't run Emacs over a slow (well say less than 1 Mbit/s)
> ssh forward X connection.

I sure have and still do every once in a while.

> Selections over slow links are painful right now.  Emacs 22 is so much
> slower in this regard than 21.x.  For example, single click with mouse-1
> sometimes makes Emacs loop forever (C-g works though), redisplay for small
> changes can take 10:s of seconds, popup of tool tip also takes several
> seconds.  Your proposal should be customizable, and preferrably default off,
> as it is a new behaviour.
[...]
> That when that amount of text gets drawn over a slow link it takes time.
> And that when Emacs redisplays, it takes time.  We are talking 10:s of
> seconds here.
[...]
> Yes, but I have to wait several seconds before Emacs is responsive again.

So again, the only argument here is that over slow links Emacs is currently
slow and my patch might make it a bit worse.

Agreed.

But since slow links are not the rule, and since Emacs is already slow over
such links (i.e. many people will prefer the -nw version in such cases),
I think that this argument shouldn't imply that the feature should be off
by default.

Those people who use Emacs over slow links will simply have to add this to
the list of features they disable to bring the delays down to an acceptable
level.  BTW, maybe we could provide a function `spare-bandwidth' that turns
off the menubar, the toolbar, the tooltips, this feature, ...


        Stefan

Re: Saving the selection before killing

[Jan Djärv]

Stefan Monnier skrev:

> Those people who use Emacs over slow links will simply have to add this to
> the list of features they disable to bring the delays down to an acceptable
> level.  BTW, maybe we could provide a function `spare-bandwidth' that turns
> off the menubar, the toolbar, the tooltips, this feature, ...

And probably font locking.  A sort of low bandwith Emacs as a parallel to lbx 
(low bandwith X).  Not that lbx is developed anymore.

I'm planning to go through the X calls Emacs does to see why 22 is so much 
slower than 21.  I'm sure some optimizations can be done.

	Jan D.

Re: Saving the selection before killing

[Richard Stallman]

    I'm planning to go through the X calls Emacs does to see why 22 is so much 
    slower than 21.  I'm sure some optimizations can be done.

Thank you!  It would be good to do this soon, so we can fix it for
Emacs 22.2.

Re: Saving the selection before killing

[Richard Stallman]

      BTW, maybe we could provide a function `spare-bandwidth' that turns
    off the menubar, the toolbar, the tooltips, this feature, ...

That sounds like a good feature in any case (though that name is not
the clearest possible).

Re: Saving the selection before killing

[Richard Stallman]

    Selections over slow links are painful right now.  Emacs 22 is so much slower 
    in this regard than 21.x.  For example, single click with mouse-1 sometimes 
    makes Emacs loop forever

Why is this?  Maybe this is a bug we should fix.

Re: Saving the selection before killing

[Jan Djärv]

Richard Stallman skrev:
>     Selections over slow links are painful right now.  Emacs 22 is so much slower 
>     in this regard than 21.x.  For example, single click with mouse-1 sometimes 
>     makes Emacs loop forever
> 
> Why is this?  Maybe this is a bug we should fix.

It is almost definitly a bug, but I haven't had the time to find it yet.

	Jan D.

Re: Saving the selection before killing

[Richard Stallman]

    Search for klipper in etc/PROBLEMS.  Now this proposal will make Emacs behave 
    like a buggy klipper.

I think that's somewhat of an exaggeration.  Emacs would only request
the selection when you type a kill command at it.

This may or may not be a good feature, but I don't think it is decided
by that.

      If the selection in large, Emacs will be slow 
    and unresponsive.

That is a real factor.  We need people to try it and see
how big a facter it is.

		       The selection may be data Emacs can't handle anyway, such 
    as audio data.

That is a real issue too.  If we make this an Emacs features,
it means, in effect, that users should check for a selection in
other windows before typing a kill command in Emacs.

So the question is whether that is a convenient way to use Emacs.

    The time it takes to send a request to the X server and get a reply.  But for 
    a "normal" X session, you almost always have a selection somewhere.

If that is true, doesn't it impact Emacs a lot?  If you go to the
Emacs window and type C-y, do you nearly always get a selection from
some other program?

Re: Saving the selection before killing

[Jan Djärv]

Richard Stallman skrev:

> 
>     The time it takes to send a request to the X server and get a reply.  But for 
>     a "normal" X session, you almost always have a selection somewhere.
> 
> If that is true, doesn't it impact Emacs a lot?  If you go to the
> Emacs window and type C-y, do you nearly always get a selection from
> some other program?

Yes, if I did something in another program before C-y.  But that is a feature,
I expect that.  But maybe 99% of my C-y is from the kill ring Emacs maintains
itself, that is a kill was made and Emacs has the selection.

Given programs like klipper, you always will have a selection.

	Jan D.

Re: Saving the selection before killing

[Richard Stallman]

    > If that is true, doesn't it impact Emacs a lot?  If you go to the
    > Emacs window and type C-y, do you nearly always get a selection from
    > some other program?

    Yes, if I did something in another program before C-y.  But that is a feature,
    I expect that.  But maybe 99% of my C-y is from the kill ring Emacs maintains
    itself, that is a kill was made and Emacs has the selection.

I asked if C-y nearly always gets you a selection from another
program, and your answer is, in effect, "It does that SOME of the
time."  In effect that doesn't really answer.

Re: Saving the selection before killing

[Jan Djärv]

Richard Stallman skrev:
>     > If that is true, doesn't it impact Emacs a lot?  If you go to the
>     > Emacs window and type C-y, do you nearly always get a selection from
>     > some other program?
> 
>     Yes, if I did something in another program before C-y.  But that is a feature,
>     I expect that.  But maybe 99% of my C-y is from the kill ring Emacs maintains
>     itself, that is a kill was made and Emacs has the selection.
> 
> I asked if C-y nearly always gets you a selection from another
> program, and your answer is, in effect, "It does that SOME of the
> time."  In effect that doesn't really answer.

Ok, I misunderstood the question.  I though it was, "Does C-y in Emacs, just 
after you done something in another program, get the selection from that 
program?".  The answer to that question is yes.

	Jan D.

Re: Saving the selection before killing

[Richard Stallman]

    Ok, I misunderstood the question.  I though it was, "Does C-y in Emacs, just 
    after you done something in another program, get the selection from that 
    program?".  The answer to that question is yes.

No, the question is, What fraction of the time, when you go to Emacs
and type C-y, does it get a selection from another program?

Re: Saving the selection before killing

[Jan Djärv]

Richard Stallman skrev:
>     Ok, I misunderstood the question.  I though it was, "Does C-y in Emacs, just 
>     after you done something in another program, get the selection from that 
>     program?".  The answer to that question is yes.
> 
> No, the question is, What fraction of the time, when you go to Emacs
> and type C-y, does it get a selection from another program?
> 

I still don't understand what you mean by "go to Emacs".  Making a selection 
in a program is a user interaction.  It is not as though some other program 
that I don't interract with steals the selection.  So about 1% of all my C-y 
in Emacs yanks the selection from another program.  But that is because I 
expect it to, I did a selection in another program before C-y.

If I interract with another program before I change to Emacs and do C-y, I'd 
say close to 100%.

	Jan D.

Re: Saving the selection before killing

[Richard Stallman]

    If I interract with another program before I change to Emacs and do C-y, I'd 
    say close to 100%.

If that's true for most users, this proposed feature is likely to be
inconvenient.  It will be pulling in lots of selections from other
apps.

The point is to have a way to pull in the selection from some other
program even after you've done a kill command in Emacs.  This way
seems not to be a good idea, so what else can we suggest?

We could create a special command that says "yank the selection".
That would require remembering something special.  Is there any other
natural combination that doesn't currently make sense?

Here's an idea.  M-y after a command that isn't a yank
could grab the selection from other programs.  Or maybe C-u M-y,
which would be less likely to be typed by accident.

Re: Saving the selection before killing

[Jan Djärv]

Richard Stallman skrev:
>     If I interract with another program before I change to Emacs and do C-y, I'd 
>     say close to 100%.
> 
> If that's true for most users, this proposed feature is likely to be
> inconvenient.  It will be pulling in lots of selections from other
> apps.
> 
> The point is to have a way to pull in the selection from some other
> program even after you've done a kill command in Emacs.  This way
> seems not to be a good idea, so what else can we suggest?

As a kill command i Emacs makes Emacs own the selection, we must pull in the 
foreign selection before the kill.

	Jan D.

Re: Saving the selection before killing

[Richard Stallman]

    As a kill command i Emacs makes Emacs own the selection, we must pull in the 
    foreign selection before the kill.

Is it impossible for Emacs to find out that the selection had a
previous owner once it has given the X call to own the selection?

Re: Saving the selection before killing

[Jan Djärv]

Richard Stallman skrev:
>     As a kill command i Emacs makes Emacs own the selection, we must pull in the 
>     foreign selection before the kill.
> 
> Is it impossible for Emacs to find out that the selection had a
> previous owner once it has given the X call to own the selection?

Yes.

	Jan D.