bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Stefan Monnier
Subject: bug#13790: Cannot paste with C-y into Homebrew emacs v24.2.1
Date: Mon, 08 Apr 2013 12:24:07 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux)

> 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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]