From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.bugs Subject: bug#13790: Cannot paste with C-y into Homebrew emacs v24.2.1 Date: Mon, 08 Apr 2013 12:24:07 -0400 Message-ID: References: <988801E5-2282-4367-A46E-7A05A63069AD@swipnet.se> <1790161F-1C74-43D3-AFEE-40EAF0B2AFBB@swipnet.se> <83obew1bub.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1365445527 1709 80.91.229.3 (8 Apr 2013 18:25:27 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 8 Apr 2013 18:25:27 +0000 (UTC) Cc: 13790@debbugs.gnu.org To: Josh Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Apr 08 20:25:27 2013 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1UPGkr-0004Y8-5s for geb-bug-gnu-emacs@m.gmane.org; Mon, 08 Apr 2013 20:25:21 +0200 Original-Received: from localhost ([::1]:51255 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UPEs8-0004Dt-8K for geb-bug-gnu-emacs@m.gmane.org; Mon, 08 Apr 2013 12:24:44 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:45823) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UPErz-00045x-Pq for bug-gnu-emacs@gnu.org; Mon, 08 Apr 2013 12:24:40 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UPEru-00011W-I2 for bug-gnu-emacs@gnu.org; Mon, 08 Apr 2013 12:24:35 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:36142) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UPEru-00011M-E2 for bug-gnu-emacs@gnu.org; Mon, 08 Apr 2013 12:24:30 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1UPEvK-00042p-7W for bug-gnu-emacs@gnu.org; Mon, 08 Apr 2013 12:28:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 08 Apr 2013 16:28:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13790 X-GNU-PR-Package: emacs,ns X-GNU-PR-Keywords: moreinfo unreproducible Original-Received: via spool by 13790-submit@debbugs.gnu.org id=B13790.136543846515523 (code B ref 13790); Mon, 08 Apr 2013 16:28:02 +0000 Original-Received: (at 13790) by debbugs.gnu.org; 8 Apr 2013 16:27:45 +0000 Original-Received: from localhost ([127.0.0.1]:40251 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UPEv2-00042I-7t for submit@debbugs.gnu.org; Mon, 08 Apr 2013 12:27:44 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.182]:25012) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UPEuz-00042B-Sh for 13790@debbugs.gnu.org; Mon, 08 Apr 2013 12:27:42 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EABK/CFFFxLSu/2dsb2JhbABEvw4Xc4IeAQEEAVYjBQsLNBIUGA0kiB4GwS2RCgOkeoFegxM X-IPAS-Result: Av4EABK/CFFFxLSu/2dsb2JhbABEvw4Xc4IeAQEEAVYjBQsLNBIUGA0kiB4GwS2RCgOkeoFegxM X-IronPort-AV: E=Sophos;i="4.84,565,1355115600"; d="scan'208";a="6869506" Original-Received: from 69-196-180-174.dsl.teksavvy.com (HELO pastel.home) ([69.196.180.174]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 08 Apr 2013 12:24:04 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 8FD0B67ADD; Mon, 8 Apr 2013 12:24:07 -0400 (EDT) In-Reply-To: (josh@foxtail.org's message of "Wed, 3 Apr 2013 10:07:20 -0700") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:73249 Archived-At: > 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-" where 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--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