bug#13790: Cannot paste with C-y into Homebrew emacs v24.2.1

bug#13790: Cannot paste with C-y into Homebrew emacs v24.2.1

[Andrew Pennebaker]

[-- Attachment #1: Type: text/plain, Size: 202 bytes --]

I can paste into emacs using Mac OS X's Command+V shortcut, but when I try
to paste text using the standard C-y command, Emacs says:

Kill ring is empty

-- 
Cheers,

Andrew Pennebaker
www.yellosoft.us

[-- Attachment #2: Type: text/html, Size: 422 bytes --]

bug#13790: Cannot paste with C-y into Homebrew emacs v24.2.1

[Glenn Morris]

Andrew Pennebaker wrote:

> I can paste into emacs using Mac OS X's Command+V shortcut, but when I try
> to paste text using the standard C-y command, Emacs says:
>
> Kill ring is empty

Anyone with Mac OS X know whether/how this is supposed to work?

bug#13790: Cannot paste with C-y into Homebrew emacs v24.2.1

[Jan Djärv]

Hello.

Both C-y and Command+V (s-v) runs yank on OSX:

"C-y runs the command yank, which is an interactive compiled Lisp
function in `simple.el'.

It is bound to C-y, s-v, <S-insertchar>, <S-insert>, <menu-bar> <edit>
<paste>."


I do not get Kill ring is empty on 24.3.
The commands are identical.  Does Homebrew modify Emacs, or is it a straight build?

	Jan D.
 
5 mar 2013 kl. 21:13 skrev Glenn Morris <rgm@gnu.org>:

> Andrew Pennebaker wrote:
> 
>> I can paste into emacs using Mac OS X's Command+V shortcut, but when I try
>> to paste text using the standard C-y command, Emacs says:
>> 
>> Kill ring is empty
> 
> Anyone with Mac OS X know whether/how this is supposed to work?
> 
> 

bug#13790: Cannot paste with C-y into Homebrew emacs v24.2.1

[Josh]

On Tue, Mar 5, 2013 at 1:46 PM, Jan Djärv <jan.h.d@swipnet.se> wrote:
> 5 mar 2013 kl. 21:13 skrev Glenn Morris <rgm@gnu.org>:
>> Andrew Pennebaker wrote:
>>
>>> I can paste into emacs using Mac OS X's Command+V shortcut, but when I try
>>> to paste text using the standard C-y command, Emacs says:
>>>
>>> Kill ring is empty
>>
>> Anyone with Mac OS X know whether/how this is supposed to work?

I use the following to integrate the OS X clipboard into Emacs:

(setq interprogram-cut-function 'paste-to-osx
      interprogram-paste-function 'copy-from-osx)

(defun copy-from-osx ()
  (let ((coding-system-for-read 'utf-8))
    (shell-command-to-string "pbpaste")))

(defun paste-to-osx (text &optional push)
  (let ((process-connection-type nil))
    (let ((proc (start-process "pbcopy" "*Messages*" "pbcopy")))
      (set-process-sentinel proc 'ignore) ;; stifle noise in *Messages*
      (process-send-string proc text)
      (process-send-eof proc)))
  text)

bug#13790: Cannot paste with C-y into Homebrew emacs v24.2.1

[Jan Djärv]

Hello. 

I don't see what you gain by doing this compared to the builtin integration. 
If you remove your code, what does not work wrt copy/paste?

    Jan D. 

6 mar 2013 kl. 00:19 skrev Josh <josh@foxtail.org>:

> On Tue, Mar 5, 2013 at 1:46 PM, Jan Djärv <jan.h.d@swipnet.se> wrote:
>> 5 mar 2013 kl. 21:13 skrev Glenn Morris <rgm@gnu.org>:
>>> Andrew Pennebaker wrote:
>>> 
>>>> I can paste into emacs using Mac OS X's Command+V shortcut, but when I try
>>>> to paste text using the standard C-y command, Emacs says:
>>>> 
>>>> Kill ring is empty
>>> 
>>> Anyone with Mac OS X know whether/how this is supposed to work?
> 
> I use the following to integrate the OS X clipboard into Emacs:
> 
> (setq interprogram-cut-function 'paste-to-osx
>      interprogram-paste-function 'copy-from-osx)
> 
> (defun copy-from-osx ()
>  (let ((coding-system-for-read 'utf-8))
>    (shell-command-to-string "pbpaste")))
> 
> (defun paste-to-osx (text &optional push)
>  (let ((process-connection-type nil))
>    (let ((proc (start-process "pbcopy" "*Messages*" "pbcopy")))
>      (set-process-sentinel proc 'ignore) ;; stifle noise in *Messages*
>      (process-send-string proc text)
>      (process-send-eof proc)))
>  text)

bug#13790: Cannot paste with C-y into Homebrew emacs v24.2.1

[Josh]

On Wed, Mar 6, 2013 at 1:34 AM, Jan Djärv <jan.h.d@swipnet.se> wrote:
> Hello.
>
> I don't see what you gain by doing this compared to the builtin integration.
> If you remove your code, what does not work wrt copy/paste?
>
>     Jan D.

-nw sessions.

$ echo 'some content on the OS X clipboard' | pbcopy
$ emacs --batch --eval '(progn (yank) (send-string-to-terminal (format
"yanked text: %s" (buffer-substring (point-min) (point-max)))))'
Mark set
Kill ring is empty
$ # `~/.emacs.d/set-up-osx-clipboard.el' is the snippet I posted previously
$ emacs --batch -l ~/.emacs.d/set-up-osx-clipboard.el --eval '(progn
(yank) (send-string-to-terminal (format "yanked text: %s"
(buffer-substring (point-min) (point-max)))))' 2>/dev/null
yanked text: some content on the OS X clipboard

bug#13790: Cannot paste with C-y into Homebrew emacs v24.2.1

[Jan Djärv]

Hello.

6 mar 2013 kl. 16:54 skrev Josh <josh@foxtail.org>:

> On Wed, Mar 6, 2013 at 1:34 AM, Jan Djärv <jan.h.d@swipnet.se> wrote:
>> Hello.
>> 
>> I don't see what you gain by doing this compared to the builtin integration.
>> If you remove your code, what does not work wrt copy/paste?
>> 
>>    Jan D.
> 
> -nw sessions.
> 

Yank from the clipboard is not available in a -nw session.
This is in line with how it works with -nw and X11.
Not sure about w32 though.

There is really no reason to make this work for -nw sessions as you can always use Command-V.
This is not a bug, just a limitation.

	Jan D.

> $ echo 'some content on the OS X clipboard' | pbcopy
> $ emacs --batch --eval '(progn (yank) (send-string-to-terminal (format
> "yanked text: %s" (buffer-substring (point-min) (point-max)))))'
> Mark set
> Kill ring is empty
> $ # `~/.emacs.d/set-up-osx-clipboard.el' is the snippet I posted previously
> $ emacs --batch -l ~/.emacs.d/set-up-osx-clipboard.el --eval '(progn
> (yank) (send-string-to-terminal (format "yanked text: %s"
> (buffer-substring (point-min) (point-max)))))' 2>/dev/null
> yanked text: some content on the OS X clipboard

bug#13790: Cannot paste with C-y into Homebrew emacs v24.2.1

[Eli Zaretskii]

> From: Jan Djärv <jan.h.d@swipnet.se>
> Date: Wed, 6 Mar 2013 19:54:40 +0100
> Cc: "13790@debbugs.gnu.org" <13790@debbugs.gnu.org>
> 
> Yank from the clipboard is not available in a -nw session.
> This is in line with how it works with -nw and X11.

Right.

> Not sure about w32 though.

You can paste on w32, but it looks to Emacs as if the characters were
typed on the keyboard.

bug#13790: Cannot paste with C-y into Homebrew emacs v24.2.1

[Josh]

On Wed, Mar 6, 2013 at 1:02 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Jan Djärv <jan.h.d@swipnet.se>
>> Yank from the clipboard is not available in a -nw session.
>> This is in line with how it works with -nw and X11.
>
> Right.

By default, yes, but this is the precise reason
interprogram-cut-function and interprogram-paste-function exist.
pbcopy and pbpaste are the OS X equivalents of xclip, and the snippet
I pasted provides an interface to them like the interface to xclip
provided by http://www.emacswiki.org/emacs/xclip.el .  Many users are
unaware of the existence of these variables, which results in
confusion and the filing of bugs such as this.  Users would be more
likely to discover them if the error messages complaining about an
empty kill ring in -nw sessions were to mention their existence.

bug#13790: Cannot paste with C-y into Homebrew emacs v24.2.1

[Stefan Monnier]

> By default, yes, but this is the precise reason
> interprogram-cut-function and interprogram-paste-function exist.
> pbcopy and pbpaste are the OS X equivalents of xclip, and the snippet
> I pasted provides an interface to them like the interface to xclip
> provided by http://www.emacswiki.org/emacs/xclip.el .  Many users are
> unaware of the existence of these variables, which results in
> confusion and the filing of bugs such as this.  Users would be more
> likely to discover them if the error messages complaining about an
> empty kill ring in -nw sessions were to mention their existence.

Indeed.  Maybe your patch should be merged with xclip.el?


        Stefan

bug#13790: Cannot paste with C-y into Homebrew emacs v24.2.1

[Josh]

On Fri, Mar 8, 2013 at 5:42 PM, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>> By default, yes, but this is the precise reason
>> interprogram-cut-function and interprogram-paste-function exist.
>> pbcopy and pbpaste are the OS X equivalents of xclip, and the snippet
>> I pasted provides an interface to them like the interface to xclip
>> provided by http://www.emacswiki.org/emacs/xclip.el .  Many users are
>> unaware of the existence of these variables, which results in
>> confusion and the filing of bugs such as this.  Users would be more
>> likely to discover them if the error messages complaining about an
>> empty kill ring in -nw sessions were to mention their existence.
>
> Indeed.  Maybe your patch should be merged with xclip.el?

I'd be happy to contribute it, though it's merely a slight
modification of a snippet I found on the web years ago, most probably
http://web.archive.org/web/20071128072321/http://blog.lathi.net/articles/2007/11/07/sharing-the-mac-clipboard-with-emacs
.  Is this code trivial enough that we needn't be concerned about
copyright issues?

Also, I see that xclip.el resides in the GNU ELPA repository.  Since
it's likely that many people using Emacs in -nw mode would like to
integrate Emacs kill and yank operations with their operating systems'
clipboards, I wonder if it would be worthwhile for some or all of
xclip.el's functionality to move into the core.  We could do this by
including a few simple wrapper functions such as the above to provide
interfaces to xclip, pbcopy/pbpaste, and whatever Windows equivalent
may exist, and mentioning those functions' existence in
interprogram-cut-function's and interprogram-paste-function's
docstrings.

bug#13790: Cannot paste with C-y into Homebrew emacs v24.2.1

[Stefan Monnier]

> I'd be happy to contribute it,

Cool.  Could you try and make it into a patch to xclip.el, then?

> Is this code trivial enough that we needn't be concerned about
> copyright issues?

Pretty much, yes.

> Also, I see that xclip.el resides in the GNU ELPA repository.  Since
> it's likely that many people using Emacs in -nw mode would like to
> integrate Emacs kill and yank operations with their operating systems'
> clipboards, I wonder if it would be worthwhile for some or all of
> xclip.el's functionality to move into the core.

I don't think xclip-mode can be enabled by default (at least not at
this stage), so the only thing we can improve is to bundle xclip.el with
Emacs, although installing a package from GNU ELPA is simple enough that
the pressure to do that is not very high.

> We could do this by including a few simple wrapper functions such as
> the above to provide interfaces to xclip, pbcopy/pbpaste, and whatever
> Windows equivalent may exist, and mentioning those functions'
> existence in interprogram-cut-function's and
> interprogram-paste-function's docstrings.

I think the current "Add (xclip-mode 1) in your .emacs" is a better
option than expecting people to mess around with their
interprogram-*-functions.


        Stefan

bug#13790: Cannot paste with C-y into Homebrew emacs v24.2.1

[Josh]

On Wed, Mar 13, 2013 at 11:04 AM, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:
>> I'd be happy to contribute it,
>
> Cool.  Could you try and make it into a patch to xclip.el, then?

OK, I took a stab at it and it seems to work correctly under OS X in
-nw mode.  I do not have access to a system running X at the moment so
someone should verify that the original functionality remains intact.

Please also review the change to the define-minor-mode form, where I
replaced the use of terminal-init-xterm-hook with direct calls to
turn-{on,off}-xclip.  I hadn't heard of this hook before and my
impression after a brief investigation is that these terminal-init
hooks are selected based on the value of TERM during initialization
and then run before user init.  If that's so then I don't see how
adding (xclip-mode 1) to users' .emacs as the commentary suggests
could possibly work, since that would cause turn-on-xclip-mode to be
added to a hook that had already run.  I assume I'm missing something
here, but someone more familiar with the init sequence than I am
should review the mode enablement implementation.

Also, if my impression that the specific terminal-init hook is
selected based on TERM is correct then I don't see how the current
implementation could be working for users with TERM set to rxvt,
screen, screen-256color, etc.

I removed the optional `push' argument to xclip-select-text because it
was unused within the function and also because xclip-select-text is a
target of interprogram-cut-function, whose docstring specifies that
its targets are called with exactly one argument.

>> Also, I see that xclip.el resides in the GNU ELPA repository.  Since
>> it's likely that many people using Emacs in -nw mode would like to
>> integrate Emacs kill and yank operations with their operating systems'
>> clipboards, I wonder if it would be worthwhile for some or all of
>> xclip.el's functionality to move into the core.

>I don't think xclip-mode can be enabled by default (at least not at
>this stage), so the only thing we can improve is to bundle xclip.el with
>Emacs, although installing a package from GNU ELPA is simple enough that
>the pressure to do that is not very high.

Enabling xclip-mode by default or at least bundling it with Emacs
seems worthwhile to me because it represents such an improvement to
Emacs' useability for -nw users.  In any case, regardless of whether
or not Emacs ships with xclip.el, mentioning its existence in the
empty kill ring error message encountered by the reporter would spur
users to investigate how to enable or install it.

Note: `xclip.el.orig' below was retrieved from
http://elpa.gnu.org/packages/xclip-1.0.el

--- xclip.el.orig	2012-11-29 08:41:30.000000000 -0800
+++ xclip.el	2013-04-03 08:40:39.000000000 -0700
@@ -28,7 +28,13 @@

 ;;; Code:
 (defvar xclip-program "xclip"
-  "Name of XClip program tool.")
+  "Path to the xclip program which provides an interface to the X clipboard.")
+
+(defvar xclip-ns-copy-program "pbcopy"
+  "Path to the pbcopy program, an interface to the Nextstep/OS X clipboard.")
+
+(defvar xclip-ns-paste-program "pbpaste"
+  "Path to the pbpaste program, an interface to the Nextstep/OS X clipboard.")

 (defvar xclip-select-enable-clipboard t
   "Non-nil means cutting and pasting uses the clipboard.
@@ -51,7 +57,7 @@
       (process-send-string proc data)
       (process-send-eof proc))))

-(defun xclip-select-text (text &optional push)
+(defun xclip-select-text (text)
   "See `x-select-text'."
   (xclip-set-selection 'primary text)
   (setq xclip-last-selected-text-primary text)
@@ -59,6 +65,20 @@
     (xclip-set-selection 'clipboard text)
     (setq xclip-last-selected-text-clipboard text)))

+(defun xclip-ns-paste ()
+  "Return the text on the Nextstep/OS X system pasteboard."
+  (let ((coding-system-for-read 'utf-8))
+    (shell-command-to-string xclip-ns-paste-program)))
+
+(defun xclip-ns-cut (text)
+  "Send TEXT to the Nextstep/OS X system pasteboard."
+  (let ((process-connection-type nil))
+    (let ((proc (start-process "pbcopy" "*Messages*" xclip-ns-copy-program)))
+      (set-process-sentinel proc 'ignore) ;; stifle noise in *Messages*
+      (process-send-string proc text)
+      (process-send-eof proc)))
+  text)
+
 (defun xclip-selection-value ()
   "See `x-cut-buffer-or-selection-value'."
   (when (and (executable-find xclip-program) (getenv "DISPLAY"))
@@ -94,8 +114,13 @@
       (or clip-text primary-text))))

 (defun turn-on-xclip ()
-  (setq interprogram-cut-function 'xclip-select-text)
-  (setq interprogram-paste-function 'xclip-selection-value))
+  (cond ((eq system-type 'darwin)
+         (setq interprogram-cut-function 'xclip-ns-cut
+               interprogram-paste-function 'xclip-ns-paste))
+        ((getenv "DISPLAY")
+         (setq interprogram-cut-function 'xclip-select-text
+               interprogram-paste-function 'xclip-selection-value))
+        (t (error "No interface to operating system clipboard found"))))

 (defun turn-off-xclip ()
   (setq interprogram-cut-function nil)
@@ -103,11 +128,11 @@

 ;;;###autoload
 (define-minor-mode xclip-mode
-  "Minor mode to use the `xclip' program to copy&paste."
+  "Minor mode to integrate operating system clipboards with kills and yanks."
   :global t
   (if xclip-mode
-      (add-hook 'terminal-init-xterm-hook 'turn-on-xclip)
-    (remove-hook 'terminal-init-xterm-hook 'turn-on-xclip)))
+      (turn-on-xclip)
+    (turn-off-xclip)))

 ;;;; ChangeLog:

bug#13790: Cannot paste with C-y into Homebrew emacs v24.2.1

[Stefan Monnier]

> Please also review the change to the define-minor-mode form, where I
> replaced the use of terminal-init-xterm-hook with direct calls to
> turn-{on,off}-xclip.  I hadn't heard of this hook before and my
> impression after a brief investigation is that these terminal-init
> hooks are selected based on the value of TERM

Yes.

> during initialization

:initialization" yes, but of the "terminal" rather than of "emacs".
E.g. with "emacsclient -t" you can create more terminals long after
Emacs has been initialized.

Here's a use case which normally works with xclip.el version 1.0, but is
currently broken with your code:
- add an unconditional (xclip-mode 1) to your .emacs.
- start Emacs with full GUI interface
- M-x server-start RET
- open an xterm and run "emacsclient -t"
- use copy & paste

> and then run before user init.

No it is done after loading the .emacs file (you can see where
`tty-run-terminal-initialization' is called from the `command-line'
function in lisp/startup.el).

> Also, if my impression that the specific terminal-init hook is
> selected based on TERM is correct then I don't see how the current
> implementation could be working for users with TERM set to rxvt,
> screen, screen-256color, etc.

The generic code runs no hook.  Instead it calls a function called
"terminal-init-<FOO>" where <FOO> is derived from $TERM (you can see how
in tty-find-type called from tty-run-terminal-initialization).
The function terminal-init-xterm (in lisp/term/xterm.el) runs
terminal-init-xterm-hook.

`terminal-init-rxvt' (in lisp/term/rxvt.el) and terminal-init-screen (in
lisp/term/screen.el) indeed do not run this hook (and don't run any
terminal-init-<foo>-hook either), so xclip.el probably doesn't work
currently with them :-(

We should maybe change tty-run-terminal-initialization to run
a `terminal-init-hook' and then xclip.el to use that hook so it also
works on terminals other than xterms.

> I removed the optional `push' argument to xclip-select-text because it
> was unused within the function and also because xclip-select-text is a
> target of interprogram-cut-function, whose docstring specifies that
> its targets are called with exactly one argument.

I can't see why this `push' arg is present, indeed.  Oh, wait, I see
that x-select-text had such an optional `push' argument in earlier
versions of Emacs, so it's either a remnant, or only needed when
running xclip.el on Emacs<24.

> Enabling xclip-mode by default or at least bundling it with Emacs
> seems worthwhile to me because it represents such an improvement to
> Emacs' useability for -nw users.

As mentioned elsewhere, it strongly depends on your use case.  If, like
me, you mostly use "emacs -nw" in remote ssh sessions, xclip-mode is
undesirable most of the time.

> In any case, regardless of whether or not Emacs ships with xclip.el,
> mentioning its existence in the empty kill ring error message
> encountered by the reporter would spur users to investigate how to
> enable or install it.

That's an idea, indeed.

Here are some further comments:

> -  "Name of XClip program tool.")
> +  "Path to the xclip program which provides an interface to the X clipboard.")

The GNU convention is to use "path" only to refer to "a list of
directories", as in `load-path', $PATH, $MANPATH, ...
So "/a/b/c" is not considered a "path" but a "file name".

> +(defun xclip-ns-paste ()
> +  "Return the text on the Nextstep/OS X system pasteboard."
> +  (let ((coding-system-for-read 'utf-8))
> +    (shell-command-to-string xclip-ns-paste-program)))

I think it's better to use `call-process' here, to avoid the
intermediate use of a shell process.

> +        (t (error "No interface to operating system clipboard found"))))

Rather than "operating system" I'd use "window system" or even just "system".

That sidesteps the whole issue of whether the GUI is part of
the "operating system" and which window-system is considered as "the
operating system" when several window-systems are in use at the
same time.

> +  "Minor mode to integrate operating system clipboards with kills and yanks."

Same here.  But I think this even deserves some additional explanation
that it only affects use under text-terminals.

> -      (add-hook 'terminal-init-xterm-hook 'turn-on-xclip)
> -    (remove-hook 'terminal-init-xterm-hook 'turn-on-xclip)))
> +      (turn-on-xclip)
> +    (turn-off-xclip)))

As explained above, this causes trouble.


        Stefan

bug#13790: Cannot paste with C-y into Homebrew emacs v24.2.1

[Josh]

Thank you for that helpful (and educational) feedback.  I regret that
I don't have the bandwidth to take this patch any farther at the
moment, but perhaps someone else will take up the task of refining it
to behave as expected for each of these use cases.

Josh

bug#13790: Cannot paste with C-y into Homebrew emacs v24.2.1

[Stefan Kangas]

Andrew Pennebaker <andrew.pennebaker@gmail.com> writes:

> I can paste into emacs using Mac OS X's Command+V shortcut, but when I try to paste text using the standard C-y command,
> Emacs says:
>
> Kill ring is empty

That was 10 years ago, so I'm reaching out to see if this is still an
issue on a modern version of Emacs.  Many changes have happened since.
I can't reproduce this myself.

If I don't hear back from you within a couple of months, Ill just assume
that this has been fixed and close this bug.

Thanks in advance.

bug#13790: Cannot paste with C-y into Homebrew emacs v24.2.1

[Stefan Kangas]

Stefan Kangas <stefankangas@gmail.com> writes:

> Andrew Pennebaker <andrew.pennebaker@gmail.com> writes:
>
>> I can paste into emacs using Mac OS X's Command+V shortcut, but when I try to paste text using the standard C-y command,
>> Emacs says:
>>
>> Kill ring is empty
>
> That was 10 years ago, so I'm reaching out to see if this is still an
> issue on a modern version of Emacs.  Many changes have happened since.
> I can't reproduce this myself.
>
> If I don't hear back from you within a couple of months, Ill just assume
> that this has been fixed and close this bug.
>
> Thanks in advance.

More information was requested, but none was given within 5 months, so
I'm closing this bug.

If this is still an issue, please reply to this email (use "Reply to
all" in your email client) and we can reopen the bug report.