all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* how to get subsequent text copies to emacs kill ring?
@ 2013-05-16 14:59 Paul K
  2013-05-16 15:05 ` Peter Dyballa
       [not found] ` <mailman.25922.1368716751.855.help-gnu-emacs@gnu.org>
  0 siblings, 2 replies; 8+ messages in thread
From: Paul K @ 2013-05-16 14:59 UTC (permalink / raw
  To: help-gnu-emacs

Hi.

I am running ubuntu 12.04 and emacs 24.

Imagine I did following action:

1) opened firefox
2) Marked text and then copied it with Ctrl-v
3) Marked another text and again copied it with Ctrl-v
3) Marked another text and again copied it with Ctrl-v

Now I switched to emacs and want to get all theese 3 copies, through emacs'
kill ring, ie: C-y, C-y M-y, C-y M-y

Is it possible???

best regards


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: how to get subsequent text copies to emacs kill ring?
  2013-05-16 14:59 how to get subsequent text copies to emacs kill ring? Paul K
@ 2013-05-16 15:05 ` Peter Dyballa
       [not found] ` <mailman.25922.1368716751.855.help-gnu-emacs@gnu.org>
  1 sibling, 0 replies; 8+ messages in thread
From: Peter Dyballa @ 2013-05-16 15:05 UTC (permalink / raw
  To: Paul K; +Cc: help-gnu-emacs Help


Am 16.05.2013 um 16:59 schrieb Paul K:

> Is it possible???

No. GNU Emacs fills its kill-ring with snippets from within. Firefox and X11 have their own cut&paste boards. Both are not synchronised. Maybe xclipboard can be useful for you as an interim storage…

--
Greetings

  Pete

"When you breath, you inspire. When you do not breath, you expire."




^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: how to get subsequent text copies to emacs kill ring?
       [not found] ` <mailman.25922.1368716751.855.help-gnu-emacs@gnu.org>
@ 2013-05-16 19:18   ` Michael Heerdegen
  2013-05-16 20:16     ` Drew Adams
       [not found]     ` <mailman.25948.1368735385.855.help-gnu-emacs@gnu.org>
  0 siblings, 2 replies; 8+ messages in thread
From: Michael Heerdegen @ 2013-05-16 19:18 UTC (permalink / raw
  To: Peter Dyballa; +Cc: help-gnu-emacs Help

Peter Dyballa <Peter_Dyballa@Web.DE> writes:

> Am 16.05.2013 um 16:59 schrieb Paul K:
>
> > Is it possible???
>
> No. GNU Emacs fills its kill-ring with snippets from within. Firefox
> and X11 have their own cut&paste boards. Both are not
> synchronised. Maybe xclipboard can be useful for you as an interim
> storage…

Having something like that in Emacs indeed would be really useful.

I think this is not trivial to implement.  Emacs has access to the
primary selection, but doesn't notice if it changes.  Any ideas?


Michael.



^ permalink raw reply	[flat|nested] 8+ messages in thread

* RE: how to get subsequent text copies to emacs kill ring?
  2013-05-16 19:18   ` Michael Heerdegen
@ 2013-05-16 20:16     ` Drew Adams
  2013-05-17  0:22       ` Stefan Monnier
       [not found]     ` <mailman.25948.1368735385.855.help-gnu-emacs@gnu.org>
  1 sibling, 1 reply; 8+ messages in thread
From: Drew Adams @ 2013-05-16 20:16 UTC (permalink / raw
  To: 'Michael Heerdegen', 'Peter Dyballa'
  Cc: 'help-gnu-emacs Help'

> > > Is it possible???
> >
> > No. GNU Emacs fills its kill-ring with snippets from within. Firefox
> > and X11 have their own cut&paste boards. Both are not
> > synchronised. Maybe xclipboard can be useful for you as an interim
> > storage.
> 
> Having something like that in Emacs indeed would be really useful.
> 
> I think this is not trivial to implement.  Emacs has access to the
> primary selection, but doesn't notice if it changes.  Any ideas?

I have often wished that I could access more items from the Windows clipboard
via the kill ring.  (But see also #6 below, which is a stronger wish.)

However:

1. Dunno whether recuperating the entire MS Windows clipboard (or another
external clipboard) - all entries - is feasible or easily realized.

(The Windows Systems clipboard holds only one entry, but the MS Office clipboard
holds up to 24.  So I guess I should say Office, not Windows, clipboard.)

2. Even if it can be easily realized, sometimes a user might want to pull in all
of the external clipboard entries, and sometimes s?he might want to pull in only
the latest entry.

3. A user option could express a user's general preference for adding to the
kill ring either the whole external clipboard or just its latest entry.

4. But even with such a preference, a user might want to override the preference
on the fly sometimes.

For instance, although I am sometimes annoyed that I cannot get to more than one
external clipboard entry from the kill ring, it is also the case that I would
not _always_ want all of the external clipboard to be prepended to my kill ring.

5. Such overriding could maybe be implemented by adding the external clipboard
entries to a separate Emacs list, which could be used together with the kill
ring.  IOW, add everything external to the separate list, but have `yank' etc.
handle the items on that list according to the user setting (#3), by default.

You would have to have a way to specify override behavior on the fly.  A prefix
key for `yank' already has another meaning, so that cannot be used to flip the
preference behavior (unless we designate a specific prefix, such as plain `C-u
C-u', for that).  An "alternate-yank" key (different from `C-y') could be one
way to get the opposite behavior to the one defined by the option.

6. To change the subject a bit, I find that what annoys me the most is not an
inability to access multiple external clipboard items from Emacs, but an
inability to access the latest external clipboard item after I have copied
something else (from Emacs) onto the kill ring.  IOW, if you want to yank the
externally copied text then you must do so immediately.

For example:

a. I hit `C-c' in a Windows app, copying selected text to the Windows clipboard.

b. In Emacs, I use `C-w' or `M-w' somewhere, adding some Emacs text to the kill
ring.

c. I want to be able to use `C-y M-y' to yank the Windows clipboard item.  Too
late.

I don't have a good answer for this, but it does annoy me from time to time.
Essentially, I have to remember to either (i) not copy or kill anything from
Emacs to the kill ring after I've copied in Windows or (ii) yank the Windows
copy immediately, then undo, then copy/kill text from Emacs etc., then later,
e.g., `C-y M-y...' to yank the Windows copy.




^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: how to get subsequent text copies to emacs kill ring?
       [not found]     ` <mailman.25948.1368735385.855.help-gnu-emacs@gnu.org>
@ 2013-05-16 23:06       ` Joost Kremers
  0 siblings, 0 replies; 8+ messages in thread
From: Joost Kremers @ 2013-05-16 23:06 UTC (permalink / raw
  To: help-gnu-emacs

Drew Adams wrote:
> 6. To change the subject a bit, I find that what annoys me the most is not an
> inability to access multiple external clipboard items from Emacs, but an
> inability to access the latest external clipboard item after I have copied
> something else (from Emacs) onto the kill ring.

Hear, hear. (Well, mutatis mutandis for Linux and OS X...)

I guess the only solution would be to place the contents of the
clipboard into the kill ring each time a kill inside Emacs is made. So a
kill would result in *two* additions to the kill ring: the external
clipboard and the text being killed. I suspect that would get annoying
real soon...

Alternatively (at least under Linux), you could (write and) run an X
server within Emacs, which would allow you to use the kill ring directly
as clipboard. (Does XWEM do this, by any chance? ;-)


-- 
Joost Kremers                                   joostkremers@fastmail.fm
Selbst in die Unterwelt dringt durch Spalten Licht
EN:SiS(9)


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: how to get subsequent text copies to emacs kill ring?
  2013-05-16 20:16     ` Drew Adams
@ 2013-05-17  0:22       ` Stefan Monnier
  2013-05-17  1:38         ` Samuel Wales
  0 siblings, 1 reply; 8+ messages in thread
From: Stefan Monnier @ 2013-05-17  0:22 UTC (permalink / raw
  To: help-gnu-emacs

> 6. To change the subject a bit, I find that what annoys me the most is not an
> inability to access multiple external clipboard items from Emacs, but an
> inability to access the latest external clipboard item after I have copied
> something else (from Emacs) onto the kill ring.  IOW, if you want to yank the
> externally copied text then you must do so immediately.

FWIW, I use a local patch which does just that (i.e. when you kill
something, Emacs first checks if there's something on the external
clipboard, and if there is, it adds it to the kill-ring just before the
thing you kill).

The main downside is that copying the content of the clipboard from some
external application can occasionally take a while, so the code needs to
be careful to timeout sufficiently quickly, and even so, the small delay
can occasionally be annoying.


        Stefan




^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: how to get subsequent text copies to emacs kill ring?
  2013-05-17  0:22       ` Stefan Monnier
@ 2013-05-17  1:38         ` Samuel Wales
  2013-05-17  5:00           ` Drew Adams
  0 siblings, 1 reply; 8+ messages in thread
From: Samuel Wales @ 2013-05-17  1:38 UTC (permalink / raw
  To: Stefan Monnier; +Cc: help-gnu-emacs

On 5/16/13, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> FWIW, I use a local patch which does just that (i.e. when you kill
> something, Emacs first checks if there's something on the external
> clipboard, and if there is, it adds it to the kill-ring just before the
> thing you kill).

(setq save-interprogram-paste-before-kill t)

-- 
The Kafka Pandemic: http://thekafkapandemic.blogspot.com

The disease DOES progress.  MANY people have died from it.  ANYBODY can get it.



^ permalink raw reply	[flat|nested] 8+ messages in thread

* RE: how to get subsequent text copies to emacs kill ring?
  2013-05-17  1:38         ` Samuel Wales
@ 2013-05-17  5:00           ` Drew Adams
  0 siblings, 0 replies; 8+ messages in thread
From: Drew Adams @ 2013-05-17  5:00 UTC (permalink / raw
  To: 'Samuel Wales', 'Stefan Monnier'; +Cc: help-gnu-emacs

> (setq save-interprogram-paste-before-kill t)

Thanks for pointing this out, Samuel!  It seems to do just what I requested.
Dunno how I missed it.

Stefan, what does your local patch do differently from what this option does?

---

I think the option name and doc for this are a bit misleading, however.

The Emacs manual, at (emacs) `Clipboard', is almost OK about this. But it
suggests that the problem, in which copied text gets "lost" or "replaced", is
that the clipboard text is overwritten by a kill or a copy to the kill ring:

 When an Emacs kill command puts text in the clipboard, the
 existing clipboard contents are normally lost.
          ^^^^^^^^^

The problem is not that the _clipboard_ gets overwritten by a kill.  It is that
the Emacs `current-kill', copied automatically from the clipboard (good), is
overwritten (replaced) by an Emacs kill or copy to the kill ring.  (When you
yank (`C-y') you get the `current-kill'.)

IOW, the problem is about the opposite of what the doc says.  It does not matter
to Emacs behavior that the clipboard gets overwritten.  What matters here is
that the "current kill", which came from the clipboard, gets replaced when you
kill text.

This problem has to do with the fact that the clipboard text was never copied to
the `kill-ring' (the list variable).  It gets treated as the (zeroth)
`current-kill', so an immediate `C-y' yanks it, but though it is called "current
kill" and it can be yanked it is not really on the `kill-ring'.

That is quite different from the behavior provided by `kill-ring-save' or
`copy-region-as-kill' - they add the text to `kill-ring', as well as making it
the `current-kill'.

A non-nil value of this option effectively copies the clipboard text to the
`kill-ring', just as `kill-ring-save' and `copy-region-as-kill' do.  And that's
all it does, I think.

The option should perhaps have been called something like
`clipboard-to-kill-ring', `copy-clipboard-as-kill', `copy-clipboard-before-kill'
or `kill-copies-clipboard-first'.  The name should, above all, say that it
causes the clipboard text to be copied to the kill ring.

A problem with such a (better) name could be that some people might think that
the clipboard text already gets copied to the kill ring anyway, without the
option, because of the curious behavior of `current-kill'.  You can yank the
clipboard text (provided you do so immediately), but it is not on the
`kill-ring'.

IOW, it might not be clear to everyone that what `C-y' yanks is the
`current-kill', which is not necessarily the first item (or any item) in the
`kill-ring'.

The Emacs doc, at (emacs) `Yanking', makes that clear:

 Emacs effectively treats "cut" or "copy" clipboard operations
 performed in other applications like Emacs kills, except that
                                 ^^^^^^^^^^^^^^^^
 they are not recorded in the kill ring.
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Regardless of this possible confusion, the most important thing the option name
could suggest is that it causes the clipboard text to be added to the
`kill-ring'.  Currently, the name does not convey that.

The current option name is also misleading because it can suggest that it
controls "pasting" in Emacs.  I'm guessing the name was taken from "interprogram
paste function", but as used here the word "paste" is misleading, even for those
who might happen to know about "interprogram paste function".

The name can unfortunately suggest that this is about saving a _paste_ from
another program (before a kill).  There is no such paste here.  And even if
there were, what does it mean to save a paste?

What happens is that before a kill (and before a copy to the kill ring, which is
also important), the clipboard text is copied to the `kill-ring'.  The doc
string should just say that:

 Non-nil means copy clipboard text to kill ring before text you kill.
 That is, when you kill or copy text to the kill ring, as its first
 item, the clipboard text is put on the ring as the second (older)
 item.  You can thus yank it using `C-y M-y'.

It could also say this, which might not be obvious though it follows from what
has already been said:

 Whatever is on the clipboard when you kill or copy in Emacs gets added
 to the kill ring.  It does not matter how long ago it was cut or
 copied to the clipboard or by which program.

The doc string can go on to point out what happens if the value is nil, and that
you can always yank the clipboard text immediately:

 If nil, clipboard text is not added to the kill ring.  Whether nil or
 non-nil, you can yank the text using `C-y' immediately after it is
 added to the clipboard.  But if nil then a subsequent kill or copy to
 the kill ring overwrites the text as the current kill, so it is no
 longer available to be yanked.

The doc string should also, like Emacs doc generally, speak of yanking, not
pasting, when it talks about yanking text in Emacs.  And whatever this doc
string says about yanking text (i.e., `C-y M-y') should be only secondary.

The point of the option is to make sure that the clipboard text gets copied
(really) to the kill ring.  What you do with text on the kill ring is secondary
here to the effect of the option.




^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2013-05-17  5:00 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-05-16 14:59 how to get subsequent text copies to emacs kill ring? Paul K
2013-05-16 15:05 ` Peter Dyballa
     [not found] ` <mailman.25922.1368716751.855.help-gnu-emacs@gnu.org>
2013-05-16 19:18   ` Michael Heerdegen
2013-05-16 20:16     ` Drew Adams
2013-05-17  0:22       ` Stefan Monnier
2013-05-17  1:38         ` Samuel Wales
2013-05-17  5:00           ` Drew Adams
     [not found]     ` <mailman.25948.1368735385.855.help-gnu-emacs@gnu.org>
2013-05-16 23:06       ` Joost Kremers

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.