I have GNU Emacs 23 (package emacs23) installed on an Ubuntu 10.04 desktop machine and package emacs23-nox installed on an Ubuntu 10.04 headless server (no X installed). Both installations have the same ~/.emacs file. I run Emacs with -nw on both computers. I don't have python-mode installed on either machine as my understanding is that this is included in Emacs 23.
On the desktop machine, comments in Python (starting with #) are highlighted in red. On the server, comments appear in plain white text like all other non-highlighted text. Any suggestions as to why comments are not being highlighted correctly on the server (nox) installation?
Update: This appears to be a terminal-related issue. I ssh into the server machine from terminator via the screen replacement byobu. If I run emacs on the server with TERM="xterm-256color" emacs, then comments are highlighted, but all the other colours look very strange.
Update: Adding `export TERM="xterm-256color" "solved" this. The syntax highlighting now has very strange colours though: purples lilacs and light browns. My green current line highlight bar is now a light pale yellow/green. Comments are highlighted in red though :)
Update: Solved. Setting TERM="xterm-color" produces "proper" colors, including highlighting of comments. The server was defaulting to a value of "screen-bce" for TERM which was not highlighting comments.
Update: Unsolved. byobu provides keybindings for various function keys to easily create new screen sessions and switch between them. When TERM is set to xterm-color, these function keys no longer work. So I guess I'll just have to be happy with unhighlighted comments in Python code in Emacs.
For me running emacs -nw from inside byobu with TERM=xterm produced the correct colours for syntax highlighting (the comments in python and bash are all red not just the #) and the function keys work. Note I set TERM as part of an alias for running emacs rather than setting it generally in .bashrc:
alias emacs='TERM=xterm; emacs -nw'
See also this post: Terminal emacs colors only work with TERM=xterm-256color
I don't have the programs you are using installed to test this, but I did notice some differences in the way the function keys are defined between screen-bce and xterm-color. You can try using the below steps to copy the settings from screen-bce to xterm-color.
Using the infocmp program, you can view the differences between the terminfo settings for two TERM settings:
infocmp -d screen-bce xterm-color
You can use infocmp to decompile the terminfo file to its source and make changes to it to try to mimic the behavior of the other terminal. Start by decoding the xterm-color terminfo file.
infocmp xterm-color > xterm-color.src
Edit xterm-color.src and modify the definitions of the kf1 through kf19 fields to match the values for screen-bce. Use infocmp to see screen-bce's definitions.
infocmp screen-bce
Finally compile using the tic program.
tic xterm-color.src
If you run it as a non-root user, it will put the compiled terminfo file into $HOME/.terminfo directory. On my system, it seems like Ubuntu picks this up automatically. You can also install it into the standard /usr/share/terminfo when you're satisfied. Running tic as root should do this for you.
Good luck!
I just added
(set-face-foreground 'font-lock-comment-face "red")
to my .emacs
Related
If I run pytest inside of Emacs, using M-X compile, $TERM gets set to "dumb", and this seems to confuse pytest's attempt to draw a line of =s across the full width of the screen. It gets the width one too high, resulting in hard to read output with extra folded lines.
Running unset COLUMNS; pytest helps a little, but it's still trying to do some fancy overwriting by issuing raw carriage-returns, and messing that up. I've also tried setting various values for $TERM (ansi, glass-tty, etc). I even tried, unset TERM.
Any way to convince pytest to just produce dumb output and not try to do any fancy output formatting?
I'm also open to ideas on how to pistol-whip emacs into setting the environment correctly :-)
I'm running:
GNU Emacs 22.1.1
Python 3.6.2
pytest version 3.4.0
MacOS 10.12.6 (16G1212)
Terminal Version 2.7.3 (388.1.1)
Try pytest.el, or at least check how it invokes py.test. I use it with Spacemacs (it's included in the Python layer), and have never seen any issues with its terminal handling.
Has anyone else ever had this error in PuTTy?
For example, pressing the Up Key now produces:
>>> ^[[A
Google doesn't let you search for special characters so I'm stumped at finding existing version of this problem.
EDIT:
So this happened after I pasted in some unicode (when, I think, the translation was already set to utf-8).
I've checked the Change Settings dialog box for different settings than my other open PuTTy windows, but the settings appear to be identical.
EDIT2:
This is fixed by restarting PuTTy, but still a nuisance.
EDIT3:
How to replicate the exact same bug:
Open a putty terminal to a linux PC (I'm using RedHat)
Open Python 2.7.* - using the command python2.7 (note: error does not appear in 2.6)
import codecs
Now use the arrow keys, and these bizarre characters appear.
In my experience that's because "bash" is not running. Simply run "/bin/bash" to enjoy colors, history and more.
I've found that specifying "The Function Keys and Keypad" option to match your operating system resolves many issues.
[Putty]
Terminal -> Keyboard --> RadioButton "Linux"
(if you're using Linux) and then you can start your session
You could try changing the 'Application Cursor Keys' mode. It's in the Terminal->Keyboard subsection of the initial configuration window (these settings may potenitally be overridden by your server).
http://the.earth.li/~sgtatham/putty/0.55/htmldoc/Chapter4.html#S4.4.4
Just run the simple bash command or sudo bash in ssh. It usually works.
For those interested in the issue, had same simptoms in a virtualenvironment, resolved the issue with
pip install readlines
See following answer for details.
Terminal >>> Local line editing >>> Force off
See also
I'm using Mac OSX Lion 10.7.2, Terminal.app supports 256 (output of :echo &t_Co).
In my vimrc I have (PATH/TO/vim/vimrc)
syntax on
filetype plugin indent on
set nobackup
When I "vim blah.py" and :colorscheme torte, syntax colors are not loading. For example python keyword doesn't have a proper colors (They have regular text color). That works for .c files but not python.
I updated my syntax/python.vim but still no luck.
Can someone tell me why?
markfw
Your answer is very good but let me just add one thing to it. In your .vimrc instead of adding just
let python_highlight_all=1
you should add it this way
autocmd BufRead,BufNewFile *.py let python_highlight_all=1
This way it only applies to Python file(s).
Hope this help.
if it works in c but not on py, the filetype file and/or syntax file is not at the right location for python.
vim manual should help you, but I also would try :scr command. This lists all the vim script loaded. So you start vim in two different way
vim your.c
vim your.py
and then in each vim session, type :scr. see how the syntax file for C is loaded (it is like chain reaction), and why it doesnt work that way for python may give you clue.
The way that I made it to work (I'm using Terminal) is to have let python_highlight_all = 1
in my ~/.vimrc file and now everything works fine and all objects such as list, tuple, ... are colored.
For more information please look at the syntax/python.vim.
Try to add the following lines to your ~/.vimrc:
set nocompatible
filetype on
syntax enabled
Quit and relaunch Vim or execute :so ~/.vimrc to reload the settings.
nocompatible remove compatibility with the original vi, this is recommended to get a fully functional Vim.
filetype on activate automatic file type detection, this is the option you want for your Python code to be colored.
syntax enabled activate code coloring, but i'm not sure if this is mandatory here.
You can get some more help by typing :help filetype in Vim.
I am new to emacs and I want to use emacs for python development. I am using Ubuntu 9.10. I frustrated to getting emacs work with python. I use GNU Emacs 23.1.50.1 (x86_64-pc-linux-gnu, GTK+ Version 2.18.0).
Here what I did.
*
Emacs come with python mode but it is confusing there are two types of mode one is python-mode.el and other one is python.el. I use emacs 23 so mine is python.el (I think). Do I need python-mode too? Code completion does not work when I press M-Tab , instead of it window manager works. I tried Esc-Tab but it says "No match" . How can I enable code completion?
After that I installed ropemacs
sudo aptitude install python-ropemacs
Then I created .emacs file at ~/.emacs
and I added followings to .emacs file
(require 'pymacs)
(pymacs-load "ropemacs" "rope-")
(setq ropemacs-enable-autoimport t)
Then when I hit M-/ (Alt-/) it doesn't work when I cick from the menu Rope->Code assist it opens a file dialog for choosing root project folder. I choose current folder which has there are some python code. When I try again Code assist from menu it says
"Completion for x: " nothing but empty set. How can make emacs python code completion work?
Then I downloaded anything.el, anything-config, anything-match-plugin to ~/.emacs.d folder Then I added following lines to .emacs file
(require 'anything-config)
(require 'anything-match-plugin)
(global-set-key "\C-ca" 'anything)
(global-set-key "\C-ce" 'anything-for-files)
Guess what it didnt work. I tried "M-x anything" again I get No match.(I guessed may me combination of C-ca (First control-a then e ) might work it says it isnt defined). Could you explain code completion for python with clear explanations (step by step) to someone dummy as me. Thanks.
Edit: I able emacs work with python with the link. Thanks all for answering
I haven't tried anything, and I haven't had much luck with rope (giant source tree causes my emacs to hang upon any file save). Instead, I find the default completion works well enough for my purposes.
The default completion keybinding is M-/. That runs dabbrev-expand which expands the current word to "the most recent, preceding word for which this is a prefix." It's not perfect: It won't parse types, and it won't search imports, but it works in 90% of the cases.
(You'll have to deactivate rope.)
I think you do want the package python-mode installed! The ropemacs variants appears to be for refactoring only, and pymacs is allows Python as an Emacs-extension language -- neither of which is what you need for standard support.
I'm not really sure you had to do anything fancy to get Python development to work. On gNewSense deltah (fork of Ubuntu 8.04) all I did was edit a .py file with the first line being:
#!/usr/bin/python
And then Emacs just figures it out and gives you python mode options. I didn't have to install anything beyond Emacs.
Then again, this may not be helpful as gNewSense pre-installs Emacs by default. I'll have to do it on one of my vanilla Ubuntu installs.
Emacs worked out of the box for me on Ubuntu 9.10.
Did you try C-c TAB (update imports) before trying code completion? I don't think it work unless you do that.
This may sound strange, but I need a better way to build python scripts than opening a file with nano/vi, change something, quit the editor, and type in python script.py, over and over again.
I need to build the script on a webserver without any gui. Any ideas how can I improve my workflow?
put this line in your .vimrc file:
:map <F2> :w\|!python %<CR>
now hitting <F2> will save and run your python script
You should give the screen utility a look. While it's not an IDE it is some kind of window manager on the terminal -- i.e. you can have multiple windows and switch between them, which makes especially tasks like this much easier.
You can execute shell commands from within vim.
Using emacs with python-mode you can execute the script with C-c C-c
you can try ipython. using its edit command, it will bring up your editor (nano/vim/etc), you write your script, and then on exiting you're returned to the ipython prompt and the script is automatically executed.
When working with Vim on the console, I have found that using "tabs" in Vim, instead of having multiple Vim instances suspended in the background, makes handling multiple files in Vim more efficient. It takes a bit of getting used to, but it works really well.
You could run XVNC over ssh, which is actually passably responsive for doing this sort of thing and gets you a windowing GUI. I've done this quite effectively over really asthmatic Jetstart DSL services in New Zealand (128K up/ 128K down =8^P) and it's certainly responsive enough for gvim and xterm windows. Another option would be screen, which lets you have multiple textual sessions open and switch between them.
There are actually 2 questions. First is polling for a console IDE for python and the second is a better dev/test/deploy workflow.
For while there are many ways you can write python code in the console, I find a combination of screen, vim and python/ipython is the best as they are usually available on most servers. If you are doing long sessions, I find emacs + python-mode typically involves less typing.
For a better workflow, I would suggest setting up a development environment. You can easily setup a Linux VM on your desktop/laptop easily these days - there isn't a excuse not to even if it's for hobby projects. That opens up a much larger selection of IDEs available to you, such as:
GUI versions of VI and friends
Remote file editing with tramp and testing locally with python-mode inside Emacs
http://www.netbeans.org
and of course http://eclipse.org with the PyDev plugin
I would also setup a SCM to keep track of changes so that you do
better QA and use it to deploy tested changes onto the server.
For example I use Mercurial for my pet projects and I simply tag my repo when it's ready and update the production server to the tag when I deploy. On the devbox, I do:
(hack hack hack, test test test)
hg ci -m 'comment'
hg tag
hg push
Then I jump onto the server and do the following when I deploy:
hg update
restart service/webserver as needed
Well, apart from using one of the more capable console editors (Emacs or vi would come to mind), why do you have to edit it on the web server itself? Just edit it remotely if constant FTP/WebDAV transfer would seem to cumbersome.
Emacs has Tramp Mode, gedit on Linux and bbedit on the Mac support remote editing, too. Probably quite a large number of other editors. In that case you would just edit in on a more capable desktop and restart the script from a shell window.
For what it's worth, VIM alone can do the same tasks as previously posted. I have had the same problem with testing Python from the command line.
My solution was to use the screen command. I split screens vertically, I run Python in one instance of a shell, and on the second screen, I usually edit Python code with VIM.
Command to install screen:
sudo apt-get install screen
The screen package has a bit of a learning curve but there isn't any mystery if you can remember the "Ctrl-Alt ?" command that contains all knowledge.
No GUI is required!