Why does tmux change the terminal from xterm to screen, and how can I fix the resulting text color change in emacs? I think the easiest way would be to prevent it from changing to screen in the first place.
I can use TERM=xterm emacs file.ext to do it temporarily, but that's just a workaround that doesn't solve the root of the problem.
Furthermore, the function keys no longer work in emacs when using tmux. Instead of F3 and F4 being macro shortcuts, they just print a tilde as they would in the shell. This seems unrelated to xterm/screen mentioned above. What is happening here, and how I can fix this?
tmux sets TERM to screen because that terminal description is limited to things that tmux knows how to work with. Like screen, tmux translates features from the outer terminal description to the inner.
If a special key (function-key, cursor-key, etc) does not have an exact match in the terminal description, tmux will ignore it.
The default configuration for PuTTY sends different escape sequences for F1-F4. The sequences which PuTTY sends are not in the terminal description for xterm.
Here's a comparison of the two (as a CSV file, but readable enough):
NAME,putty,xterm
kf1,\E[11~,\EOP
kf2,\E[12~,\EOQ
kf3,\E[13~,\EOR
kf4,\E[14~,\EOS
kf5,\E[15~,\E[15~
kf6,\E[17~,\E[17~
kf7,\E[18~,\E[18~
kf8,\E[19~,\E[19~
kf9,\E[20~,\E[20~
kf10,\E[21~,\E[21~
kf11,\E[23~,\E[23~
kf12,\E[24~,\E[24~
kf13,\E[25~,\E[1;2P
kf14,\E[26~,\E[1;2Q
kf15,\E[28~,\E[1;2R
kf16,\E[29~,\E[1;2S
kf17,\E[31~,\E[15;2~
kf18,\E[32~,\E[17;2~
kf19,\E[33~,\E[18;2~
kf20,\E[34~,\E[19;2~
You'd have trouble getting PuTTY to send F13-F20, but will certainly run into trouble using PuTTY and tmux with TERM=xterm.
Regarding colors, the same issue applies. The screen terminal description tells applications that the terminal can support 8 colors, and tells how to display those eight colors. If your external terminal can do more, then tmux and screen hide that.
The conversion is not perfect. GNU screen has a feature where it looks for a corresponding screen.$TERM terminal description (i.e., concatenating the outer TERM value to screen). tmux does not do that: it makes assumptions regarding xterm. But PuTTY is not xterm...
ncurses has several of those concatenated terminal-names for terminal descriptions, but no one has suggested a way for tmux to use them automatically.
Related
I am trying to use org-mode and whenever I press Crtl+return emacs does C-J instead. I know this because when I use c-h k and then press crtl+return, emacs shows:
"It is bound to C-j."
Is there anyway I can make it register ctrl+return so I can insert headings?
I am using emacs23 through the terminal on ubuntu 12.04 x64. When I do this on my windows machine it does insert a new heading.
Possibly. As #phils says, C-Enter is usually not a valid sequence for the vast majority of terminal emulators. This is because when you press a key, or key combination, the terminal sends a sequence of characters to the relevant application. Pressing a sends a, whereas Enter sends CR - carriage return (otherwise known as ^M, \r or \015).
What sequences are actually implemented in modern terminals is mostly just a hang-over from the earlier, physical, terminals that they emulate (notably the VT-100). These machines didn't allow the use of Ctrl in conjunction with every key, such as the function keys, for example, so C-F1 was not possible and didn't have an escape sequence defined. Similarly, there is no control sequence for C-Enter, so when you press it, the terminal ignores the Ctrl and just sees the Enter.
You may, however, be able to define your own escape sequences in your terminal, which you can then bind to the correct key combinations in emacs. See here, for example. I was able to use this method to be able to use C-Enter. Unfortunately, this is still a bit of a pain, as it requires a lot of configuration and you may still be unable to use some sequences (C-M-% doesn't work in konsole for me). As with #phils, I've taken to using the GUI, but I'd love to have better integration with my terminal.
That's not a valid sequence for most terminals, I'm afraid, so they simply can't send it to Emacs.
If you run GUI Emacs instead, the key bindings will work.
Thomas Dickey's xterm is the only terminal software I know of which can (I think) support all the normal Emacs bindings. If you're okay with compiling that, then you could try it with the following .Xdefaults-(hostname) (or .Xresources if you re-merge after editing) to get basic support working:
XTerm*metaSendsEscape: true
XTerm*modifier: meta
XTerm*modifyOtherKeys: 1
You actually need XTerm*modifyOtherKeys: 2 to fully extend the sequences (otherwise you still can't type the likes of C-M-%), but by default that setting will break most key sequences, and right now I couldn't tell you how to configure things correctly for that setting (the only example I've seen -- xterm-extras.el as mentioned on the wiki and available in the easymacs download -- didn't work for me).
I mostly use GUI Emacs, but I'd love to get this working properly, so if anyone has had success with xterm-extras.el or similar, please do speak up.
If you're willing to install an Emacs package and configure your terminal, I wrote an Emacs package which can teach Emacs and terminals how to properly recognize all PC keyboard keys and modifier key combinations:
https://github.com/CyberShadow/term-keys
Its default configuration enables encoding the CtrlReturn combination, which allows Emacs to distinguish it from CtrlJ.
When I open files with emacs it adds 12;rgb:1c1c/1c1c/1c1c on the top. How can I prevent this?
I have installed emacs on a clean reinstalled debian system.
Emacs: GNU Emacs 24.4.1
Terminal Emulator: MobaXterm Personal Edition v7.7
System (local): Windows 7 Ultimate
System (remote): Debian 8.0 "jessie" stable
As noted, "MobaXterm" is not "xterm". According to its webpage it is
Based on PuTTY/MinTTY with antialiased fonts and macro support
Lacking a detailed change history, and the problem reported by the OP, it seems that MobaXterm is based on PuTTY from a while back, and does not implement all of the control sequences which PuTTY does, much less those of xterm.
The particular sequence which is not recognized (referring to XTerm Control Sequences) may be this:
OSC Ps ; Pt ST
OSC Ps ; Pt BEL
...
Ps = 1 2 -> Change text cursor color to Pt.
That is part of a group of controls predating ANSI color support in xterm, referred to as dynamic colors.
Based on comments in other places, it seems that the problem could lie within the OP's Emacs configuration, by using scripts which do an ad hoc test of TERM to decide if it can do colors, rather than inspecting the terminal capabilities. See Terminal emacs colors only work with TERM=xterm-256color where someone worked around this problem by modifying their init.el to add special cases for rxvt and xterm.
Emacs of course is capable of doing colors in different terminals. See emacs colors based on $TERM environment variable for comments. And TERM=xterm on Debian has provided color for quite a while. So in a typical configuration, color should "just work".
However, there are different ways to configure Emacs. Attempting to reuse some 256-color script can fall into the hole dug by developers who assume that every terminal is just like the one in front of them. See the Emacs wiki page X Term Colors for an example.
!! SOLVED IN MOBAXTERM VERSION 8.2 !!
Looks like your terminal settings are out of sync. The settings of your terminal need to agree with the termcap/terminfo settings on the server. Try to set the TERM variable in the shell on the server to a value which better matches the terminal emulation capabilities of your terminal (common values are xterm, xterm-color, vt520, and vt102) or correspondingly change the settings of the terminal to match the current TERM value. (If the terminal is buggy, you may need some trial and error to find a mode which works well for you.)
VT220 works fine; Edit Session / Terminal Settings / Type: vt220
I use urxvt (terminal) under awesome (window manager) and ubuntu (os).
In graphical mode, c- set the mark but in text mode it inserts a space.
The problem is solved when using gnome-terminal but some other key combinations still does not work. For instance, C-: insert a : in both terminals.
I do not know where to look at to correct this behaviour.
C-h k (help on key combination) followed by one of these combination shows only the key pressed along ctrl, for instance C- is interpreted as .
As stated in comments, the terminal is probably the cause. I believe that C- should not enter a space at the terminal prompt, which it does here.
I identified this question as being related. This one too.
In my case, Ctrl-Space was being used to change input methods. Running ibus-setup and unbinding it fixed my problem (it now produces Nul)
See also: https://askubuntu.com/questions/243639/ctrlspace-has-been-bound-to-invoke-some-input-method-and-does-not-work-in-ema
I've found that terminal emacs does not render the correct colors unless I explicitly set TERM=xterm-256color. I use gnome-terminal, and from what I understand, TERM should be set to gnome-256color. Similarly, I tend to use tmux a lot, which advises against any TERM setting other than screen-256color. Unfortunately, both of those settings (within their respective context - gnome-terminal or tmux) result in emacs having wrong colors, whereas vim displays colors correctly. However, if I export TERM=xterm-256color, the colors work just fine in emacs.
Can anyone explain what's going on, or offer a solution?
Update
Here's what I'm dealing with:
I can get the colors to look correct in the terminal by adding the following to my init.el:
(defun terminal-init-gnome ()
"Terminal initialization function for gnome-terminal."
;; This is a dirty hack that I accidentally stumbled across:
;; initializing "rxvt" first and _then_ "xterm" seems
;; to make the colors work... although I have no idea why.
(tty-run-terminal-initialization (selected-frame) "rxvt")
(tty-run-terminal-initialization (selected-frame) "xterm"))
This feels really, really wrong though. There has to be a logical explanation for this...
P.S.
I have very little knowledge of terminfo and the precise role that $TERM plays in the process of color terminal behavior. If it's safe to always use xterm-256color (even when $TERM "should" be gnome-256color or screen-256color), I'll go with that.
Maybe I'm not understanding something, buy why don't you run emacs like this:
TERM=xterm-256color emacs -nw
This way Emacs has its own TERM setting that you know works. You can also make an alias or wrap this in shell-script.
Terminals are a special type of device. When a process sends special byte sequences (called control sequences) to the terminal, it performs some action (like cursor positioning, change colors, etc).
You can read the ANSI terminal codes to find more detail about control sequences.
But terminals come from 70s, when hardware was limited in its capabilities, and a terminal cannot provide info about its capabilities (ie. which sequences it supports).
$TERM was used to resolve this issue - it allows programs to know what to send to the terminal to get the job done. termcap and terminfo are databases that store info about terminal capabilities for many $TERM names. If your $TERM is not in the db, you must ask an administrator to add it.
All terminal emulators inherit these limitations from old hardware terminals. So they need a properly set $TERM, and the terminfo/termcap DB MUST have data for this terminal. When a virtual terminal starts it sets the $TERM variable for you (and inside programs like bash). If $TERM is not in the terminfo/termcap you can quickly define an alias from $TERM to xterm-256color (you can find examples in the termcap file on how to do that).
This behavior has to do with the logic EMACS uses to determine whether the terminal background is dark or light. Run M-x list-colors-display with TERM set to either xterm-256color or screen-256color and you'll see that the exact same colors are listed. As you pointed out in the comments, the difference in color schemes that you've observed is due to the frame background mode. To see this, with your TERM set to screen-256color, compare the colors in
emacs -Q -nw --eval "(setq frame-background-mode 'light)"
and
emacs -Q -nw --eval "(setq frame-background-mode 'dark)"
The function frame-set-background-mode (in frame.el) checks to see whether the terminal type matches "^\\(xterm\\|\\rxvt\\|dtterm\\|eterm\\)" if it can't deduce the background color otherwise.
Within a running session, you can change the color scheme to 'light by evaluating
(let ((frame-background-mode 'light)) (frame-set-background-mode nil))
I am not that familiar with how emacs handles different terminals exactly. But looking at lisp/term directory in emacs sources, I found out that the existence of a function terminal-init-xxx allows you to add support for different terminals. For example, I've got:
(defun terminal-init-screen ()
"Terminal initialization function for screen."
;; Use the xterm color initialization code.
(xterm-register-default-colors)
(tty-set-up-initial-frame-faces))
in my .emacs, which adds support for screen-256color. You may try defining a similar function for gnome by renaming the above function to terminal-init-gnome.
NOTE: If you are interested, you can try to track down the calls from tty-run-terminal-initialization code. It first gets the terminal type using tty-type function, then looks at certain locations to load a relevant terminal file, then tries to locate the matching terminal-init-xxx function, and finally calls it. It may help you figure out the correct name for gnome-terminal.
It looks like unless your TERM indicates that your terminal has 256 colors, emacs will only use 8. Changing TERM to gnome-256color allowed the color registration functions to work.
There is a way to cheat, after all. When I run gnome-terminal, my terminal is set to xterm by default. Instead of changing TERM variable, it is possible to redirect xterm to another terminal, say, gnome-256color. Simply create the directory $(HOME)/.terminfo/x, then run ln -s /usr/share/terminfo/g/gnome-256color ~/.terminfo/x/xterm. I think this is better than setting TERM manually in .bashrc, because it only redirects a particular terminal to something else. A console login would still leave TERM as linux, and not xterm-256color.
Add this to your ~/.emacs:
(add-to-list 'term-file-aliases
'("st-256color" . "xterm-256color"))
It tells emacs that if it sees TERM=st-256color then it should initialize the terminal as if it had seen TERM=xterm-256color.
Longer answer:
Emacs is showing strange colors because it thinks your terminal can only support 8 colors. In Emacs, run M-x list-colors-display to see the colors it thinks are available. The correct number of colors is detected during terminal-specific initialization. It says, in part:
Each terminal type can have its own Lisp library that Emacs loads when run on that type of terminal.
On my machine, the terminal-specific initialization files are in /usr/local/share/emacs/25.*/lisp/term. It has files for xterm, rxvt, screen, etc. but nothing for st. We need to help Emacs find the right initialization file. The documentation further says:
If there is an entry matching TERM in the term-file-aliases association list, Emacs uses the associated value in place of TERM
So that association list is a recommended way to handle unknown terminals. It works without you having to manually override the TERM environment variable.
On ubuntu 10.04 I too had noticed that running emacs -nw inside byobu/tmux/screen was using different colours from emacs -nw in the regular gnome-terminal.
I found that this is because byobu was setting TERM to screen-bce. Then setting TERM to xterm (for me, in the normal gnome-terminal TERM=xterm) gave me the same syntax highlighting when not running through byobu/screen.
So still not sure what the proper solution is.
See also this post:
Emacs Python-mode syntax highlighting
I'm using zsh in OS X Terminal.app and for quite a while, I've been longing for a way to jump back and forth between prev/next prompts in the terminal's output.
One convenience with this would be to be able to review (and track errors at) the end of each command's output; eg. when you building stuff from source with ./configure; make; make install. Note: I'm obviously not referring to jumping back and forth in the command-history, but for a way to take a peek at the endings of each command's output.
Has anyone heard of such functionality in the *nix (preferrably also Mac) world? Would it require some sort of OS-centric Terminal plugin, or can it be programmatically done via a shell script which can be tied to a keyboard shortcut? Maybe I'm the only one thinking about this? :)
Edit: Here's an example scenario: Let's say I want to compile and install some program (using standard ./configure && make && make install procedure) and after the make command, I run into some errors. Now, the way I understand it (I may be completely wrong), the crucial error causing the make command to fail usually shows up in the last line(s) in the output, no? Anyway, at this point, I might do something like cat INSTALL to read up on the INSTALL document to check whether there's something I've missed. NOW, if I want to go back to see what the error was, that caused my initial make command to fail, I then have to manually scroll up to that position again, since my cat INSTALL command printed a ton of text after it.
I don't know if this scenario is the most elucidative – but there are many other situations where I wish I could just "jump" back to previous prompt lines and check up on previous command output; whether it was a simple ls command, make, git status, or whatever it was – swapping positions in the window by means of using prompt lines as "bookmark" positions seems an interesting idea to me.
command + left or right goes between tabs in iterm. is this what you are asking?
Emacs has a shell-mode that runs a shell inside the Emacs editor, providing a rich environment of additional commands for navigating and working with shell commands. This includes commands for going to the previous/next prompt, and deleting the output from commands so you can "clean up" and issue another command.
If you aren't familiar with Emacs: to start a shell inside Emacs, run emacs from the shell, then type Esc-x (or Meta-x, if you have "Use option as meta key" enabled in Terminal > Preferences > Settings > [profile] > Keyboard). This will ask for a command to execute. Enter shell.
To see a list of commands you can use in Shell Mode, enter Control-h m. Here are the ones for moving the cursor to the previous/next prompt:
C-c C-n comint-next-prompt
C-c C-p comint-previous-prompt
These commands would also be useful:
C-c C-r comint-show-output
C-c C-o comint-delete-output