Python indentation

[Jacek Generowicz]

"Process Python exited abnormally with code 1"

Is there a way to get any info about why the Python process failed?

You could start by looking at the python interpreter Emacs is trying
to run:

C-h v py-python-command RET

or

M-x describe-variable RET py-python-command RET


If that looks dodgy, try changing it to something sensible. One way to
do that is

M-x customize-group RET python RET

.... and then do the mousey-clickety thing that seems relevant.

 

[Martin Christensen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Michele> Is there a way to get any info about why the Python process
Michele> failed? (did I mention I am a rather poor emacs user?

In addition to Jacek's tips, you can also check the *Messages* buffer
for clues. That's always a good place to start. Oh, and make sure that
the Python executable is in your path. That bit is not entirely
unimportant.

Martin

- --
Homepage: http://www.cs.auc.dk/~factotum/
GPG public key: http://www.cs.auc.dk/~factotum/gpgkey.txt
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using Mailcrypt+GnuPG <http://www.gnupg.org>

iEYEARECAAYFAkD3rTQACgkQYu1fMmOQldU+sQCeJET5eKVWzmo+N9KefyfxlOLv
LYEAnjDQe+IEto5jYhy/5YqxvD/5bbAS
=KgLH
-----END PGP SIGNATURE-----

 

[Steve Lamb]

Don't be a moron.

First step, read the help. .... Oh sorry, forgot.

Emacs allows me to interact with a continuously live instance of the
Python interpreter.

You know, oddly enough this isn't something I demand of my editors. With
things like screen, konsole, multiple rxvts or even plain old ALT-F1, ALT-F2 I
get the exact same functionality. It's called learning how to use the tools
given instead of insisting on having everything bolted onto one large
bloatware application.

 

[Jacek Generowicz]

You know, oddly enough this isn't something I demand of my editors.
With things like screen, konsole, multiple rxvts or even plain old
ALT-F1, ALT-F2 I get the exact same functionality.

Of course, and with a Turing machine I get exactly the same
functionality as I do in Python.

It's called learning how to use the tools given instead of insisting
on having everything bolted onto one large bloatware application.

You know, I always believed that vim was an excellent tool, the tool
of choice of many intelligent power-users.

The contributions of you and your Kamikaze chum are the first instance
of something managing to make me start questioning that belief.

Good riddance.

 

[Mark 'Kamikaze' Hughes]

Don't be a moron.
If you want to help me help vi users, and have the knowledge, then

I already did. You're just too stupid to actually use that help.

please contribute it ... otherwise sod the $%^& off. Incremental
Python development in vi is of no personal interest to me, and if I
have to put up with your moronic insults to get at it, it becomes less

I gave you useful information, and you spat in my face. Go screw
yourself, cretin.

<http://kuoi.asui.uidaho.edu/~kamikaze/doc/plonk.html>

 

[Michele Simionato]

You could start by looking at the python interpreter Emacs is trying
to run:

C-h v py-python-command RET

Thanks Jacek, this did the job. py-python-command was set to
"/usr/bin/env python"
and Mandrake was not happy about that, for some reason.
I solved setting py-python-command to "/usr/bin/python". Now it works.
Still, it is not as handy as in Scheme/Lisp where I can execute the block
by just giving C-x C-e after the last parens (ah, how bad Python lack of
parens

BTW, if someone needs tips for programming Scheme with emacs my suggestion
is to try quack.el by Neil van Dyke (google is your friend).


Michele Simionato

 

[Jacek Generowicz]

Thanks Jacek, this did the job. py-python-command was set to
"/usr/bin/env python"
and Mandrake was not happy about that, for some reason.
I solved setting py-python-command to "/usr/bin/python". Now it works.
Cool.

Still, it is not as handy as in Scheme/Lisp where I can execute the block
by just giving C-x C-e after the last parens (ah, how bad Python lack of
parens

Indeed ;-)

C-M-x is a poor-man's alternative which does the job in a limited set
of cases, in Python ... limited, but still useful.

 

[Jacek Generowicz]

I'd like to apologize for posting previous message to the group at
large. I should have refrained from posting to this thread a while
ago, when it became clear that nothing constructive would come of it.

 

[Steve Lamb]

I'd like to apologize for posting previous message to the group at
large. I should have refrained from posting to this thread a while
ago, when it became clear that nothing constructive would come of it.

IE, from your very first post since you're the one being completely
unconstructive?

 

[Lonnie Princehouse]

I think what he was trying to say is this: for each time you send a

code snippet to the interpreter, a new interpreter is started, and
afterwards you won't have the same interpreter and its state to play
with.

If you use :!python, then of course you're starting a new python
session each time, because it's just running the interpreter via
system()...

BUT if you use ython, it will keep a persistent embedded interpreter
sitting around. Try it:

ython foo=5
ython print foo

Reading the help file on ython is highly recommended! The vim
module* is really spiffy.

*only works from inside the embedded interpreter, e.g. ython import
vim


Also-- I don't know of any code that does it, but it would be pretty
straight forward to (1) grab the vim cursor location (2) parse the
buffer into an AST (3) figure out where the cursor is inside the AST
and (4) do clever things like name completion, show function
arguments, and even interact with the debugger.

 

[Ville Vainio]

Jacek> large. I should have refrained from posting to this thread
Jacek> a while ago, when it became clear that nothing constructive
Jacek> would come of it.

From vi vs. emacs discussion? Surely, you must jest ;-).

 

[G. S. Hayes]

Mark> It sends the entire selected block to a new interpreter, yes.
Mark> Not each line to a different interpreter, if that's what you're
Mark> trying to say.

I think what he was trying to say is this: for each time you send a
code snippet to the interpreter, a new interpreter is started, and
afterwards you won't have the same interpreter and its state to play
with.

With Emacs' Python mode, you can run a so-called inferior Python
process, which is just to say that you have an interpreter running in
Emacs. You can then keep sending code to this same interpreter. [SNIP]
I should be greatly surprised if it weren't possible to do something
similar in at least Vim.

http://www.vim.org/scripts/script.php?script_id=165

The vimsh package allows you to run a shell under Vim; among other
things, you can run python under this shell. I do this all the time,
with macros to run selected line(s) from my python code in the Python
window, maintaining state in between sending lines through Python--so
running "i=100", then going back to editing and later running "i=i+1",
"print i" will print 101.

This runs seperately from Vim's built-in Python interpreter, so you
don't have to worry about namespace collisions, etc (in fact, you can
easily have several vimsh python windows each running their own
interpreters, just like in emacs).

vimsh doesn't have smart terminal emulation (just dumb ptys), though,
so you can run line-oriented programs fine this way, but you can't run
e.g. curses or advanced termcap programs in any useful way. Not a big
deal for me.

Sumner

 

[Martin Christensen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Steve> You know, oddly enough this isn't something I demand of my
Steve> editors. With things like screen, konsole, multiple rxvts or
Steve> even plain old ALT-F1, ALT-F2 I get the exact same
Steve> functionality. It's called learning how to use the tools given
Steve> instead of insisting on having everything bolted onto one large
Steve> bloatware application.

You know, it strikes me as odd that you are so quick to dismiss the
usefulness of something you have not tried in practice. I have tried
it, and I very much miss it when it's not there.

As for the whole 'bolted on' thing... being able to interact with
another process is useful for a wide range of things, as I'm sure any
purist vi user will agree. Also vi can run such processes, sending
input to them and doing something with the output. This particular
feature of Emacs' is simply having input to and output from the
process in the same buffer, and it's reused widely. I've already sung
the praise of its usefulness for interactive programming in Python and
similar languages, but I've also found it invaluable e.g. for
interacting with SQL databases (anyone who've used Oracle's sqlplus
can surely quickly be persuaded of this), where the output is
something that you'll often want to fiddle around with in your editor
anyway. Well, at least I do.

Now, if it's possible to run a Python process separately from vi which
you can send code snippets to anytime, then you can conveniently have
your small, separated tools and the functionality that Jacek and I are
so fond of at the same time.

As for the whole bloatware argument, I think it's getting a bit
ridiculous. Fine, I build Python into Vim, and I'm all for that. I'm
sure that means that I can hook into a _lot_ of Python code that way,
thus making Vim every bit as much bloatware as Emacs is. Seriously, if
you want a slim Emacs, don't load all the things you won't need. Sure,
you'll never cut Emacs down to the minimum size of any vi
implementation, I'm sure, but it was never designed for extreme
compactness. At the computer science department I very recently
graduated from (yay me!), Emacs was used significantly more than vi on
our application servers, and none of our application servers have ever
had scarceness of resources because of it. Sure, on a mobile phone or
PDA with very limited resources, I might start to worry about size,
but with even relatively low-end machines having at least 256 MB main
memory these days, fussing over a couple of megs for something as
important as the text editor one uses, which is probably in the top
three of the most important programs people like us use, is nothing
but pedantry. If that's what's going to tip over your box, it's time
to put the old 386 out of its misery. Hell gVim compiled with Python
support alone takes up 7.5 MB at startup on my box compared to Emacs'
8.2 MB with my own 'basic' stuff loaded (which is quite a lot for
some). Is it really a big deal? It certainly isn't to me.

Martin

- --
Homepage: http://www.cs.auc.dk/~factotum/
GPG public key: http://www.cs.auc.dk/~factotum/gpgkey.txt
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using Mailcrypt+GnuPG <http://www.gnupg.org>

iEYEARECAAYFAkD4R+AACgkQYu1fMmOQldWB8ACg5GMNmMhC2IALb62dhMlu8dRh
hJwAnjengArZINHPWOIYcXRuIqcFT+pu
=32eg
-----END PGP SIGNATURE-----

 

[Eli Stevens (WG.c)]

You really use ed, don't you ?

Real Men(tm) don't use ed, they use cat.

# cat > hello.py
prn^D

# cat > hello.py
print "Hello, Wolr^D

# cat > hello.py
print "Hello, World!"
^D

I've actually done this, but not for files that long.

Eli

--
Give a man some mud, and he plays for a day.
Teach a man to mud, and he plays for a lifetime.
WickedGrey.com uses SpamBayes on incoming email:
http://spambayes.sourceforge.net/
--

 

[Roy Smith]

Real Men(tm) don't use ed, they use cat.

# cat > hello.py
prn^D

# cat > hello.py
print "Hello, Wolr^D

# cat > hello.py
print "Hello, World!"
^D

I've actually done this, but not for files that long.

I once knew a guy who linked /dev/tty to /dev/tty.c, then he could do
"cc /dev/tty.c" and type in a C program to compile.

 

[Steve Lamb]

I once knew a guy who linked /dev/tty to /dev/tty.c, then he could do
"cc /dev/tty.c" and type in a C program to compile.

Of course now there's tcc.

 

[Dan Sommers]

I once knew a guy who linked /dev/tty to /dev/tty.c, then he could do
"cc /dev/tty.c" and type in a C program to compile.

For short programs on many common architectures, use this:

gzip -d >a.out

For longer programs, revert back to this (because the string tables are
too big to commit to wetware):

cat >a.out

Regards,
Dan

 

[Steve Lamb]

You know, it strikes me as odd that you are so quick to dismiss the
usefulness of something you have not tried in practice. I have tried
it, and I very much miss it when it's not there.

Who said I've never tried it?

 

[Jacek Generowicz]

If you use :!python, then of course you're starting a new python
session each time, because it's just running the interpreter via
system()...

BUT if you use ython, it will keep a persistent embedded interpreter
sitting around. Try it:

ython foo=5
ython print foo

OK, so this could be one way of emulating the REPL (but I hope that
there might be a more convenient way).

Reading the help file on ython is highly recommended!

I don't doubt that for one second ... but how do you do it?

[ ... time passes ... ]

OK, I've tried it again, and discovered that you can scroll beyond the
bottom of the screen ... and then some actual information
appears. Phew, what a relief! (On my previous attempt, I thought that
that the |python-commands| &co next to the 5 numbered titles were
links of some sort, and everything I tried resulted in frustration.)

So, am I right in thinking that it's just a single chunk of text, with
some colouring ... which one is supposed to read by scrolling up and
down, or is there more to it (it _looks_ as if there is ...) ?

I guess I really should find the time to go through this with an
interested vim user.

*only works from inside the embedded interpreter

Hmm, that makes me slightly nervous ... do you get to see some
vi-specefic inerpreter state ... with which you might clash ?

 

[Jacek Generowicz]

http://www.vim.org/scripts/script.php?script_id=165

The vimsh package allows you to run a shell under Vim; among other
things, you can run python under this shell. I do this all the time,
with macros to run selected line(s) from my python code in the Python
window, maintaining state in between sending lines through Python--so
running "i=100", then going back to editing and later running "i=i+1",
"print i" will print 101.

This runs seperately from Vim's built-in Python interpreter, so you
don't have to worry about namespace collisions, etc (in fact, you can
easily have several vimsh python windows each running their own
interpreters, just like in emacs).

vimsh doesn't have smart terminal emulation (just dumb ptys), though,
so you can run line-oriented programs fine this way, but you can't run
e.g. curses or advanced termcap programs in any useful way. Not a big
deal for me.

Sounds promising. Thanks for the pointer.

Just one thing (and please remember that I do not use vim, so much of
this is alien to me) ... I heard it mentioned a number of times that
Python must be compiled into vim, and in the link you posted the words
"for python enabled [g]vim" appear. Is vim typically Python-enabled
out of the box, or does the user have to compile it in? The problem is
that we have a lot of centrally managed software here, and if users
will need to replace the standard vim with their own version, then
that is likely to lose a lot of potential users.