Every time I use emacs, I can use the arrow keys just fine to move the cursor around. But when I'm running emacs within screen, and I push emacs to the background (ctrl-Z) then return it to the foreground, my arrow keys no longer work, e.g.
M-[ a is undefined
This behavior doesn't happen when I'm running emacs outside of screen.
Any ideas? Is this some screen setting?
For what it's worth, this just happened to me, and I was able to correct it by disconnecting from screen and then reconnecting:
Ctrl+A, d
screen -R
The vt100 terminal that Screen (and just about every other terminal emulator) emulates has two modes, normal mode and application mode. Normal mode is used for line-by-line applications and application mode for full-screen applications. Amongst the differences between the modes is that the arrow keys send different control sequences (I don't know why): e.g. ESC O A in full screen mode and ESC [ A in normal mode. It seems that when you press Ctrl+Z, Emacs switches the terminal back to normal mode, but when you return it to the foreground, it doesn't switch to full screen mode again, or Screen does not react to Emacs's commands properly.
One possible workaround is to bind the same character sequences in both modes in your .screenrc, e.g.
bindkey -k ku stuff ^[OA
bindkey -k kd stuff ^[OB
bindkey -k kr stuff ^[OC
bindkey -k kl stuff ^[OD
Another possible workaround is to tell Emacs to interpret both key sequences regardless of what the terminal says. Although this is in principle a bad idea since some terminals might use these key sequences for different keys, I've never encountered such an incompatible terminal, and I suspect none have been made in the last 20 years or more.
(define-key function-key-map "\eOA" [up])
(define-key function-key-map "\e[A" [up])
(define-key function-key-map "\eOB" [down])
(define-key function-key-map "\e[B" [down])
(define-key function-key-map "\eOC" [right])
(define-key function-key-map "\e[C" [right])
(define-key function-key-map "\eOD" [left])
(define-key function-key-map "\e[D" [left])
A true solution would involve finding what's causing the problem. It could be a bug in Screen, a bug in Emacs, a bug in the terminal (emulator) that Screen is running in, a bug or misconfiguration in your termcap or terminfo database. If you want to investigate this, start by mentioning your operating system, what terminal (emulator)(s) Screen is running in, where you obtained Screen (or how you compiled it, if that's what you did) and what version, ditto for Emacs, whether you've observed the same problem outside Screen, the output of echo $TERM and echo -E "$TERMCAP" inside Screen.
I had my xterm window full screen and was in screen and this happened.
I double clicked the xterm border to go out of full screen. Ctrl-z to background emacs. Then fg to bring it back and then the arrow keys worked. I could go into full screen without any issues.
I should proly learn all the emacs navigation commands but my old habits of migrating to the arrow keys die hard :/
First, push emacs to background.
Ctrl+z
and bring to forefront again.
fg
Not an answer, but worth noting that the described behaviour also occurs when running GNU emacs on tmux on Ubuntu's Terminal or xterm
Quick work around is to not run emacs in tmux.
Versions
Emacs: GNU Emacs 24.3.1 (x86_64-pc-linux-gnu) of 2014-06-06 on brownie, modified by Debian)
tmux: 1.9
Ubuntu: 14.10
We're having the same problem here, a workaround we found, (but we still need to find the origin of the problem) is to set the "application sequence" manually from within emacs:
Navigate to your *scratch* buffer
Paste: (send-string-to-terminal "\e[?1h")
M-x eval-buffer
and voilà.
Also, a simple C-z fg may be enough, and is faster to type þ
Here's a solution that worked for me to unbreak it once broken (ubuntu 14.04, emacs 24.1). Without detaching from the screen try the following:
1) Ctrl-z to stop emacs.
2) Start another emacs: emacs -nw
3) Ctrl-z in second emacs, and voila!, first emacs will work again. (I then reopen the second emacs and close it Ctrl-x Ctrl-c).
Related
I've been opening emacs from the terminal but every time I want to compile my c program, i have to quit emacs first, compile it on terminal, then re-open emacs afterward again to edit some more.
Is there a simpler way to do this so I can keep emacs open while also compiling stuff on terminal?
I know this has something to do with entering shell mode but I'm not too familiar with that or editing the init file as im really new to emacs and still trying to get the hang of it
Any help is appreciated, thanks!
To compile your program while inside Emacs, type M-x compile and enter the compilation command. As a bonus, any errors or warnings in the output become links to the corresponding line in the source code.
Once your program is compiled, there are a few different ways to run it. If it's a non-interactive program, you may find that M-! (for running a shell command, waiting for it to finish, and displaying its output in a buffer) is sufficient. Otherwise, you may want to run a shell inside Emacs. You can do that with M-x eshell. (Some people prefer M-x shell; try both and see what you like.)
Alternatively, if you want to temporarily leave Emacs and go back to the terminal, you can type C-z to put Emacs in the background. To go back from the shell to Emacs, type % or fg (for "foreground"). To check whether Emacs is currently running in the background, type jobs.
Alternatively, it's straight-forward to run M-x ansi-term to have a functioning terminal inside of an Emacs buffer. It's nice having a working, interactive terminal in Emacs but also to be able to navigate that terminal output using your normal Emacs key bindings.
I use this this package to make sure all my environment variables are loaded.
Some operational notes:
When I'm editing something in Emacs and in need of a terminal, my usual procedure is to split vertically 'C-x 2' or horizontally 'C-x 3' in order to be able to open a terminal emulator (either 'M-x eshell' or 'M-x shell') side by side with the actual window. From here it is possible go forward and backward with 'C-x o' or 'C-u C-x o' as needed. This allows to continue editing while something is running visibly on the near window.
In rare cases where these emulators dont work exactly as the real OS terminal, we can split and use the native thing without layer or emulation 'C-x term RET RET' . Unfortunatly, in the later case, it is not possible to cycle between the framed windows (with 'C-x o') . Here, the exit command is required to be able to operate normally with emacs.
I am not able to set the mark at the current point by C-SPC (both when emacs loads the init file and when it doesn't). However, when I do M-x set-mark-command, the mark is well set and I am able to select the region by moving the cursor. When I do M-x apropos set-mark-command, it shows two bindings C-# and C-SPC, but only the first one works. Any suggestions will be appreciated.
I am running emacs 24.3 on a GUI on Kubuntu 14.04.
Ubuntu 14.04 has an open bug affecting some desktop environments (at least KDE, LXDE and i3, but not Unity).
The default IBus key binding for "next input method" is Ctrl+Space, which prevents this key combination from reaching Emacs (or any other userspace program). To resolve the issue, run ibus-setup and change the key binding for "next input method" to something else (or delete it entirely by clicking the "..." button and then the "Delete" button).
Note that running ibus-setup from Unity, where C-SPC works already, shows a preferences window that does not include the key binding option that needs to be changed.
The "next input method" command cycles through your configured inputs, e.g. perhaps from English to French.
So I tracked down a similar issue to this on macOS. It seems that at some point C-SPC became bound to "Select the previous input source":
I just had the same issue today which I never had before. I am on Windows 7. As it turns out the Ctrl+SPC is bound to the OS's language switch. So the keystrokes are not sent to emacs at all.
But one thing that is even more weird is that I have never installed new languages/keyboards, yet the 'CH PRC' shows up in my language bar as a language/keyboard today. It turns out to be a Windows 7 bug and all I had to do to fix was:
Add 'CH PRC' in the language bar then Save.
Remove the language then Save again.
I know you are not on Windows, so the fix may not be the same as mine, but it is very likely Ctrl+SPC is bound to your OS's language switch as well.
I would like to attach screen or tmux inside emacs, in shell mode. I often find myself running emacs with inferior processes inside screen on remote servers; it would be nice if I could shift the workflow to local emacs + TRAMP; ability to reattach persistent sessions is a must, however. (Such workflow is particularly useful for analysis in R [1])
Shell-mode is rather desirable because I keep encountering miscellaneous glitches and even crashes when using the combination of M-x term or M-x ansi-term + screen + R. However, I can't seem to get rid of ansi colored rendered as escape codes in screen when run under M-x shell. When I use ansi-color-for-comint-mode-on, they are fine -- but as soon as screen comes on, it becomes a horrible mess.
Has anyone figured out the set of conditions for proper interpretation of ansi color with shell + screen or tmux? What about getting rid of color altogether?.. Are there any other alternatives in terms of running persistent remote processes and attaching them to local emacs?..
[1] http://blog.nguyenvq.com/2010/07/11/using-r-ess-remote-with-screen-in-emacs/
As far as I can tell, Screen requires features of your terminal that Emacs' shell mode simply does not and cannot provide, simply because it is not a traditional character terminal like VT100. So the issue is not about getting rid of or trying to interpret color codes -- there are more terminal capabilities that Screen requires to function correctly.
By default Screen does not even start in Emacs' shell mode, as far as I can tell (it errors out saying it needs clear screen capability). Some posts around the web seem to suggest setting TERM=xterm to work around this, but it is just fooling Screen into thinking the terminal has the capabilities of XTerm, which it doesn't have.
The term and ansi-term modes of Emacs would provide the terminal capabilities required by Screen, but unfortunately you seem to have had troubles with those modes.
What I would suggest instead would be to have a look at the "emacsclient -t" command (part of Emacs), which allows you to open a local frame connected to an existing Emacs instance in a similar way as Screen allows you to reconnect to a previously created Screen instance. That way you could perhaps configure a emacsclient on you local computer to reconnect over TCP to a persistent remote Emacs instance.
I don't use screen, but maybe you can fix this from your .bashrc. I've got a bunch of conditional code in there, turning color on for xterm windows, but leaving it off for other terminals that don't support it. M-x shell sets the TERM variable to dumb, so you can test for that and set the color accordingly.
case "$TERM" in
dumb)
## non-color settings here
;;
xterm)
## color settings here
;;
*)
## default (maybe you want non-color here?)
;;
esac
When I open an emacs buffer in the terminal using
emacs -nw
C+arrow does not move me around like I would like it to.
Is there a way to change this behavior?
There are two steps to fix this.
First find out what your terminal is sending emacs. This can be done right inside emacs by hitting C-q then the combination you want to see, say C-⇒ or something.
Then in your .emacs, you can bind the combination to whatever you want. For example, if you want C-⇒ to go to the next word, you can use (global-set-key "<your combination here>" 'forward-word). Do the same for the other bindings.
I have that sometimes in combination with screen. I run emacs as a daemon -- just disconnect that screen 'window' (or is it called panel or session?) and reconnect and you should be fine.
No idea what upsets the terminal settings.
I'm running emacs on a terminal mode (no window system) emacs -nw. I've few global keys defined in emacs like C-; C-x C-/ C-, etc.. These control keys aren't taken for account in -nw mode. Any work around or solution please ?..
I just ran into this problem myself. Basically, terminals are ASCII based, so key combos like C-' don't register. See this answer on serverfault.