I am unable to yank text into a terminal running in Emacs.
This is my procedure:
I killed the string "date" from one buffer and yanked it into the terminal in another buffer and hit return.
The terminal behaves as if I typed nothing. It just returns the prompt back.
I am using OS X 10.5.8 and Emacs 23.1. I have tried this procedure on Aquamacs, Carbon Emacs, and the release from http://emacsformacosx.com/. They all show this weird behaviour even in their default configurations with my .emacs file empty. What could possibly be causing this?
By "in a terminal" I assume you mean you're running Emacs's built-in terminal emulator. Ordinarily, the terminal emulator transmits most keys exactly as typed to the shell process. Type C-c C-j in the terminal buffer to put it into a state where ordinary Emacs key bindings are available. You'll see the mode line change from (Term: char run) to (Term: line run).
Addendum:
Yanking text without leaving char mode is a little tricky; the relevant function, however, is term-paste (not yank, which merely inserts the text into the terminal buffer without sending it to the inferior process). term-paste will immediately send the most recent kill to the inferior process, but doesn't provide the fancy yank functionality you're probably used to (like M-y to cycle through prior kills). You could run term-paste as an extended command: C-c M-x term-paste RET.
Probably the easiest solution is just to temporarily go into line mode (C-c C-j) when you have something to paste, and then immediately go back into char mode (C-c C-k). Or even easier, just stay in line mode all the time. I often do this when I have a terminal logged into an Oracle SQL*Plus session. I rarely notice the difference, but I get all sorts of convenient Emacs functionality, like being able to type M-p to cycle through a long, previously-typed SQL statement.
I would have assumed that you could always start off in line mode like this:
(add-hook 'term-mode-hook 'term-line-mode)
...but it doesn't work for me. Don't know why.
In the buffer with the terminal running, put the terminal into line mode with C-c C-j. To paste in your text, now press S-Insert (that's Shift-Insert). If you need the terminal to go back to char mode afterwards, it's C-c C-k.
When all else fails I just highlight the text and click Edit->Copy then right click in the other emacs buffer and click paste.
Related
For some reason, I'm loosing the up-arrow and DEL keys after launching GHCi from within an ansi-term window in Emacs.
(These keys work as expected from within the ansi-term window, before launching GHCi.)
And RET doesn't produce a line feed, just a carriage return.
I don't observe any of these oddities when launching GHCi from my normal Terminal application under MacOS X.
Using Emac's view-lossage feature I find:
<menu-bar> <Terminal> <Character mode> [term-char-mode]
<up> [term-send-up]
<return> [term-send-raw]
<backspace> [term-send-backspace]
<menu-bar> <Terminal> <Line mode> [term-line-mode]
<up> [previous-line]
<return> [term-send-input]
<backspace> [delete-backward-char]
C-h l [view-lossage]
(Note: The above was taken after launching GHCi from within the ansi-term window of Emacs.)
And it looks like I may want to switch to Line mode while running GHCi.
(I normally run the ansi-term window in Character mode, because it gives me an experience more similar to working in the Terminal application.)
It looks like M-p will recover past commands.
So, if I can figure out how to get the up-arrow remapped to M-p while in GHCi, then I should be pretty close to my usual GHCi-in-Terminal experience.
However, there's one remaining problem: I'm still not getting a line feed when hitting RET.
And this is really screwing things up, both asthetically and functionally.
It's strange, because the RET key typed at either the ansi-term prompt, or the GHCi (launched from within ansi-term) prompt (with the ansi-term window set to Line mode) both send the same command: term-send-input.
And the ansi-term does the right thing in response to this command.
So, why doesn't GHCi do the right thing?
Perhaps, I need to remap RET to: CR/LF; term-send-input while in GHCi?
Is this even possible (i.e. - doing application-specific key remapping withing the ansi-term window)?
I am aware of this option:
Kill the *terminal* buffer with C-d
But I am still a newbie in emacs, what is the original method to do this? I tried C-x k but it doesn't like it, C-x C-c kills all my windows and buffers...
I assume you're using a buffer in term-mode (M-x term). term-mode is a bit different than most modes in that it has two submodes, char and line. In char mode it acts more like a terminal than emacs, as in a lot of normal keybinds are not available. Put it in line mode with C-c C-j to put it in line mode, then you can run most normal keybinds including C-x k. You can put it back into char mode with C-c C-k.
I use the multi-term package, which I think has better defaults than plain term-mode and as the name suggests makes it easy to have many terminal buffers.
I have happily been using emacs's LaTeX mode for years (decades?). Up to emacs version 24.2.1, if I type C-c C-c in a LaTeX buffer that I was editting, the following would happen:
A prompt appears in the minibuffer for me to save, which I can acknowledge by pressing y.
A prompt appears in the minibuffer for me to latex the file, which I can acknowledge by pressing return.
latex is run on the file in the background. If there are no errors, a message in the minibuffer tells me so.
If there are errors, I am prompted to press C-c ` to examine them. This also (usually) takes me exactly to the the location of the error in the .tex file.
Only if I press C-c C-c again without making changes to the buffer, a propmt appears in the minibuffer for me to open the .dvi in xdvi, which I can acknowledge by pressing return.
I like the above behavior. It usually does what I want.
In 24.3.1, if I type C-c C-c in a LaTex buffer that I am editting, this is what happens:
A prompt appears in the minibuffer for me to run xdvi. I must type "latex" and press return. (xdvi is already open on the file, so why would I want to open it again?)
A prompt appears in the minibuffer for me to save, which I can acknowledge by pressing "y".
The frame is split into two windows. The latex command is run in a tex-shell in the bottom half.
If the latex run was successful, I must manually remove the tex-shell window from the frame, since it is waste of screen real estate.
If the latex run was unsuccessful, I must scroll through the tex shell buffer to see where they happened. Then I must seach the .tex manually file to find the corresponding code.
This is basically a disaster.
Is there some way to restore the old behavior?
Note: Please don't tell me to "use AUCTeX". If I had wanted to use auctex, I would doing so by now.
I'm using emacs 23 (acquamacs) and have installed nrepl.el.
I've evaluated some Clojure code with
C-c C-p
(this key combo is to Evaluate the form preceding point and display the result in a popup buffer.)
Running it has produced a nice popup buffer for me to see the results.
How do I hide this popup buffer? (I don't want to kill it - just get my fullscreen back).
FYI Re this command - I've run this with
C-h k C-c C-p
and got
^C ^P runs the command nrepl-pprint-eval-last-expression, which is an interactive compiled Lisp function in `nrepl.el'.
It is bound to ^C ^P, <menu-bar> <nREPL> <Eval last expression in popup buffer>.
(nrepl-pprint-eval-last-expression)
Evaluate the expression preceding point and pprint its value in a popup buffer.
You haven't provided enough information for anyone to test (that's not a standard global binding), and you haven't even indicated whether the new window is selected; but there's a generic solution which will work regardless.
Add (winner-mode 1) to your init file, and then you can always use C-c<left> to undo the most recent window configuration change (or changes plural, if you repeat the command).
Either that or just press q. I just tried it out with the help buffer and it dismisses the window but not the buffer. However, popup buffers in the style of ac-nrepl does for its autocompletion are meant to simply be dismissed
Always, when asking Emacs questions, say what the key sequence does. C-c C-p does nothing here. TO find out what it does press C-h k C-c C-p and report back. In this case we're invoking 'describe-key and then telling it to describe what C-c C-p does.
Update
What's happening is that whenever I kill some text, it gets added to the kill-ring followed by an extra "". Then C-y just inserts the "". So the question is where is the extra "" coming from?
Original Question
I'm running emacs under tmux, and I can't get C-y (or even M-x yank) to insert content from the kill-ring. I do see Mark set in the minibuffer, which is normal behavior for yank; I just don't see anything getting yanked. I also see that "" gets added to the kill-ring each time I hit C-y.
I know that C-y is getting received by emacs by looking at the output of M-x view-lossage, and I know that C-y is bound to yank by looking at the keybindings with C-h b. Moreover, running M-x yank directly gives the exact same results.
When I repeat the experiment outside of tmux, it works as expected. For what it's worth, if I repeat the experiment with screen instead of tmux, C-y works as expected.
Some more details are that within tmux, I have tried running emacs with TERM=xterm-256color and TERM=screen-256color with the same result. Setting xterm-keys on or xterm-keys off in tmux doesn't seem to matter either. I've been closing every tmux session between each permutation I try, to make sure that my .tmux.conf is getting re-processed (And I know it is because other changes in my .tmux.conf do have an effect.)
In fact, I can even comment out my entire .tmux.conf, with the same result.
Also, I've tried it in both iTerm2 and Terminal.app (I'm on a mac), again with the same result.
So, I feel like I am at a dead-end here. Any ideas on how to better debug this problem?
I finally tracked it down to some code I had copied into my emacs init.el to allow copy-and-paste from my OSX clipboard. If I remove that code from my init.el, C-y works fine under tmux. (The code is here -- it worked great until I decided to try out tmux!) I'm still not sure exactly what the problem is, but it's easy to believe that it would affect the behavior of C-y.