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
Related
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.
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.
IPython's history-search-backward feature is one of my favorite features. history-search-backward allows you to type part of a command and then search backward through your readline history for commands that began with that part of the command. By default (I believe) these are bound to UpArrow or Ctrl+P and DownArrow or Ctrl+N (for backward and forward respectively).
They are not working for me. Instead they just go linearly through my history instead of taking into account the characters I've already typed to (allgedly) filter my history.
I'm running IPython 0.13.2 (with Python 2 and 3) on Arch Linux from within XTerm.
If I hit Escape, Ctrl+P, then UpArrow and DownArrow work exactly as I want them to.
Additionally if I change my ipython_config.py to include
c.TerminalInteractiveShell.readline_parse_and_bind = ['"\\e[B": history-search-forward', '"\\e[A": history-search-backward']
then I can just do Escape UpArrow for the desired behaviour. (Here's the rest of my config file.)
Ctrl+V UpArrow produces ^[[A as I expect. I have the python readline library installed (which seems to fix common problems with macs running IPython).
I have these lines in my .bashrc
bind '"\e[A": history-search-backward'
bind '"\e[B": history-search-forward'
and they work exactly as I want them to within bash.
I have no idea what else to try next, so I've come here. Please help, I hope I've included enough information and done enough research.
The culprit was set keymap vi set in my .inputrc. I removed that and IPython history went back to what I expected. Thanks to #Thomas K!
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 am using emacs 23.2 on Ubuntu 10.04 & Windows XP along with cedet extention. Cedet seems to work fine but I could not select the file using mouse. Rather I need to use the Key press to select the file from cedet (placed at left side)..
how to do file selection using mouse with emacs cedet? Any clue shall be appreciated...
CEDET is a collection of features, so I'm not sure specifically which one you're talking about, but are you left-clicking or middle-clicking the mouse? The middle mouse button is more commonly bound to an 'open file' command in Emacs modes.
In any case, you can always use C-h m to list the help for the active major mode in a buffer, along with any minor modes. Key bindings are frequently listed in this help text.
Finally, as you know a working key binding, you can trivially find out what else is bound to the same command: C-h k <working binding> will tell you which command that key is bound to, as well as any other bindings for the same command. If there are no other bindings that are to your liking, then you can always define your own.