Really annoying problem in ipython prompt in emacs:
In [128]: if 1==1:
.....: print "yes"
.....: else:
.....: print "no"
.....:
IndentationError: unindent does not match any outer indentation level
It looks perfectly aligned to me, not sure what trigger the error. No such problem when I do this in terminal.
You might try toggling autoindent with
%autoindent
since I think that has caused the problem for me before.
You can change this permanently using ipython's customization. After the proper imports (see the link) the following should work in ipy_user_conf.py:
# Emacs sets the term to dumb so we can distinguish that way
if os.environ['TERM'] == 'dumb':
ip.options.autoindent = 0
Yeah, this is strange. On my end, using the standard python interpreter within an emacs shell works fine when evaluating your code, but using ipython fails. If you're using the python-mode.el package, you probably need to install ipython.el to get proper ipython support. OTOH, if you're using the python.el that normally ships with emacs, you may have to switch to the standard python interpreter (I believe ipython.el is only intended for use with the third-party python-mode.el package, not the python.el that emacs uses by default).
Related
For reasons outside of my control I'm stuck using python 2.6.6 and IPython 0.10.2. I also normally use the tcsh shell, and have gotten quite used to completing a command from the history using <A-p> (i.e. pressing the ALT key and p). However, this doesn't work in IPython. I know I can press <C-r> and then start typing a command, but what inevitably is happening is that I start a command, press <A-p>, get a colon indicating some weird state, then exit out of that state, delete my command, press <C-r> then search for my command. It's getting rather irritating. Is there any way to make <A-p> complete my already started command by relying on the history?
Ouch, this is an old version of IPython, Python (and pip). The bad news is I don't have much experience with such an old version of IPython, the good new is; it was way simpler at that time.
Most of the shortcut and feature are provided using readline, and the python bindings of stdlib. Meaning that most likely what you are trying to configure is readline itself and not only IPython; so you can find more information on that outside of IPython !
The secret is to grep in the source-code for parse_and_bind, then you'll find the following example configuration, leading me to change the ~/.ipython/ipy_user_conf.py to be like so at around line 99 (all indented an extra 4 space to be in the main() function):
import readline
readline.parse_and_bind('set completion-query-items 1000')
readline.parse_and_bind('set page-completions no')
rlopts = """\
tab: complete
"\C-l": possible-completions
set show-all-if-ambiguous on
"\C-o": tab-insert
"\M-i": " "
"\M-o": "\d\d\d\d"
"\M-I": "\d\d\d\d"
"\C-r": reverse-search-history
"\C-s": forward-search-history
"\C-p": history-search-backward
"\C-n": history-search-forward
"\e[A": history-search-backward
"\e[B": history-search-forward
"\C-k": kill-line
"\C-u": unix-line-discard"""
for cmd in rlopts.split('\n'):
readline.parse_and_bind(cmd)
The repetition of commands make me think that what \C,\M or [e mean might be system dependant. I would bet on \C being Control, and \M being Meta (Alt, Opt), but at least one of these line did the trick for me (and also now tab allows to complete). See also man readline for the list of commands you can bind to what, and enjoy! Hoping you can upgrade to Python 3 and IPython 6 at some point.
[Edit]
See Eric Carlsen second comment under this answer for how it was resolved.
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
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 like to do my Scala development in Emacs, and from time to time, I use the REPL to test out snippets of code or to load and test some code I've just written. I'm using Scala 2.9.1, and I've noticed that when I open the REPL in a terminal buffer, things are substantially broken. In particular, I am unable to remove any characters from the current line, and cannot move the cursor backward on the current line. This is highly frustrating as any time I mistype something, I have to begin the command anew. I was wondering if anyone else is having this problem using the Scala REPL under Emacs, and if anyone has a potential solution.
I find that rlwrap (readline wrapper) plays well with emacs' ansi-term and scala. Just call "rlwrap scala", and you'll have the usual bash line editing, as well as history, working properly. As a bonus, your history will span multiple invocations of scala, so you won't lose everything you've typed after exiting the Scala REPL.
If rlwrap doesn't work for you, just switching to line-mode in ansi-term (C-x C-j by default) will allow you to use emacs-style editing on the line, but without the shell niceties like history and completion.
Ensime has already been mentioned, so I'll just second that as a great option if you don't mind the setup involved.
You may install ENSIME and follow instructions. I don't know about your way to invoke REPL, but REPL called from ENSIME works (it allows moving the cursor backward and deleting symbols, I've checked).
You could try using the ammonite repl, amm. I can confirm tab completion works in the emacs ansi-term. This is true for its default mode (based on stty) or you can use JLine3 with amm. Note that the Dotty (tentative Scala 3) repl, dotr, is also based on amm and also has working tab-completion in ansi-term.
I'm playing with Paul Graham's arc, and it's getting really annoying that the up arrow inserts ^[[A instead of the previous command, and ^R doesn't work as in shell. I vaguely remember there being a simple way to run Arc's REPL in a program which will remember the input history - does anyone know what it is?
Perhaps you're thinking of rlwrap?
I like rlwrap too, but other options include:
Emacs modes:
shell
term
comint
Slime (works with Common Lisps and Clojure, probably not with Arc)
ssfe (the frontend part of sirc)
jline (especially if the REPL is written in Java, which arc is not)
nex3's arc on github comes with a script arc.sh which calls rlwrap by default, and an emacs mode to use the history with alt+P and alt+N.