By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
445,908 Members | 2,055 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 445,908 IT Pros & Developers. It's quick & easy.

IDE

P: n/a
Hello

I am probably going to start a war now... but so be it :)

I just want to hear what all you guys who eat pythons for breakfast use
for python coding. Currently I use Kate, but I would really like an IDE
with debugger and a source browser (ie. one the I can use to browse
through modules etc. when looking for just the right curses stuff and such
- I am a newcomer to Python).

.... and no, Emacs or Vi are not what I want :)

--
Mvh.
/Thomas

Jul 18 '05 #1
Share this Question
Share on Google+
49 Replies


P: n/a
Thomas Lindgaard <th****@it-snedkeren.BLACK_HOLE.dk> writes:
I just want to hear what all you guys who eat pythons for breakfast use
for python coding. Currently I use Kate, but I would really like an IDE
with debugger and a source browser (ie. one the I can use to browse
through modules etc. when looking for just the right curses stuff and such
- I am a newcomer to Python).


If you want to target .Net:

http://www.activestate.com/Products/Visual_Python/

I thought they had something for "non-.Net" Python as well, but can't
see anything.
Jul 18 '05 #2

P: n/a
Thomas Lindgaard wrote:
Hello

I am probably going to start a war now... but so be it :)

Mmm editor wars.
I just want to hear what all you guys who eat pythons for breakfast use
for python coding. Currently I use Kate, but I would really like an IDE
with debugger and a source browser (ie. one the I can use to browse
through modules etc. when looking for just the right curses stuff and such
- I am a newcomer to Python).

For Win32, PythonWin (though it doesn't have what I think you're
thinking of as a "source browser"). For Linux, Eric3 (make sure to get
the latest release, Gentoo, at least, has an old one as "stable"), which
is probably what you want (since you mention the KDE editor Kate).
SciTe is also popular, but it's a bare-bones editor, while Eric is an
all-singing-all-dancing IDE. Finally, though I've not tried it, Eclipse
apparently has some Python plugins somewhere.

Have fun,
Mike

________________________________________________
Mike C. Fletcher
Designer, VR Plumber, Coder
http://members.rogers.com/mcfletch/
blog: http://zope.vex.net/~mcfletch/plumbing/

Jul 18 '05 #3

P: n/a
On Wed, 14 Jul 2004, Mike C. Fletcher wrote:
For Win32, PythonWin (though it doesn't have what I think you're
thinking of as a "source browser").


Actually, it does (Tools->Browser, Tools->Browse PythonPath). It even has
COM browsing built in (at least in the ActiveState version, unsure about
the others). Nifty stuff!

Also, pydoc should suffice for most "source browsing" needs: pydoc -p 8080
(python c:/python23/Lib/pydoc.py -p 8080 on Windows) will start an HTTP
server on localhost:8080 you can use for module browsing (even of your own
classes). pydoc -g will do the same, but also pop up a nifty little
search window.

Jul 18 '05 #4

P: n/a
Up until about a month ago, I used Boa (the cvs version), ActiveState's
PythonWin (great help file!), and SciTe.

But then I took another look at Wing IDE. Check out their new beta
version 2.0 --- it's $179 US, but is *very* good compared to the 'free'
alternatives. We liked it so much that we bought 11 developer licenses.
You can download a 10 day trial (extendable for another 10 days) to
see for yourself.

http://c2.com/cgi/wiki?PythonIde lists the other Python IDEs out there.

Paul

Jul 18 '05 #5

P: n/a
Thomas Lindgaard wrote:
Hello

I am probably going to start a war now... but so be it :)

I just want to hear what all you guys who eat pythons for breakfast use
for python coding. Currently I use Kate, but I would really like an IDE
with debugger and a source browser (ie. one the I can use to browse
through modules etc. when looking for just the right curses stuff and such
- I am a newcomer to Python).

... and no, Emacs or Vi are not what I want :)


you might want to try SPE http://spe.pycs.net/ which altough a 0.5
release is quite stable and has lots of features which might come in
handy...

cheers
chris
Jul 18 '05 #6

P: n/a
Tor Iver Wilhelmsen wrote:
...

If you want to target .Net:

http://www.activestate.com/Products/Visual_Python/

I thought they had something for "non-.Net" Python as well, but can't
see anything.


http://www.activestate.com/Products/Komodo/

Paul Preacod
Jul 18 '05 #7

P: n/a

Let's not do the war thing :-) But perhaps an exchange of information?

Me, I use Emacs - have done so for 20 years now with never a regret. When I
see a feature that I like (enough) in another editor I implement it in Emacs
(if it doesn't already have it - something that is getting harder and harder
to do these days :-)). I understand completely that many do not like Emacs
because of the "magic incantations" required to run commands i.e. sets of
key sequences - but I don't like using mice and menus - takes longer than
keyboard access (right hand off the keyboard onto the mouse, then back
again) and how else can you provide efficient access to such a wealth of
commands? :-) But I shouldn't digress into look and feel - many an argument
could be had with a Vi user over that! :-)

So what are the interesting "features" (as opposed to "I just like the look
and feel of editor X" - I don't desire a discussion on "warm, fuzzy
feelings" about your favourite editor - we all know how "religious" these
things can be :-)) in any of the editors that people have settled upon for
their personal use? For example the following comment is made in another
(later) thread:

"augment Leo's mind blowing qualities" - which means what? :-) Other than
the fact the writer likes Leo? :-)

I'll (attempt) to kick the discussion off with the features of Emacs that I
like and use in everyday programming of Python (not necessarily in order of
importance :-)):

1. available for any OS/platform that I have worked on over the last 20
years and the forseeable future - the one time I couldn't get a native
binary was for VMS and the company didn't want the expense of installing NFS
so then I used the (transparent) ftp access built into Emacs to edit files
on the VMS file system all from a PC running Windoze (ange-ftp allows
editting of files that are accessed using standard ftp operations but are
hooked into the standard Emacs read/write file commands - so the user is
"unaware" of the file access mechanism).

2. the (obvious) generic IDE capability i.e. compile and debugging from
within the editor

3. code completion - a la LSE from the VMS editor of that name (see the
reference to ELSE on http://www.python.org/cgi-bin/moinmoin/EmacsEditor) -
note this is not "syntax completion", although I have written some code that
allows scanning of Python modules and then generation of code templates for
ELSE that generate call templates with the named parameters filled in and
code templates for where the coder must supply the arguments. But I guess I
am not big on "syntax completion" - I haven't really used to the code since
I wrote it, although I do use ELSE itself extensively in writing my Python
code :-)

4. User extendable using either Lisp or Python ( :-) ) - (see the reference
to Pymacs on http://www.python.org/cgi-bin/moinmoin/EmacsEditor).
"Extendability" of the editor to create new commands/functionality as
opposed to "macro" capability.

5. Integration with Ispell/Aspell i.e. Emacs is intelligent enough to spell
check only the comments and strings - which can be extremely handy when
writing code! Nothing more embarrassing than a poorly spelt message to a
user! :-)

6. Unix "screen" like capability i.e. having multiple "virtual" instances of
the editor (each with its own window/buffer view) available via simple key
switching - but not "cluttering" the Windoze landscape with multiple
instances (although you can configure Emacs to work that way too :-)).

7. Given sufficient physical screen real-estate, you can "split" the editor
display into multiple "windows" - both horizontally and vertically - the
number of "splits" limited only by the physical display. My "faviourite"
configuration is two vertical, 80 column windows side-by-side - one or both
then generally get split horizontally as I look at other files or positions
within the same file.

8. "Free" - in this day of powerful editors that are available for zero
cost, why purchase one? Either shareware or commercial?

9. syntax highlighting (almost not worth mentioning since it is so common?)

These are just some of the reasons I use Emacs. What features of *your*
editor attracted you? How does it help you with writing Python code (the
intent after all of this news group :-)). Does your editor have a feature
that I have not listed above and yet you consider it *essential* (or at
least very handy :-)) in your generation of Python code?

So whilst I know that Thomas does not "want Emacs or Vi", I believe my
response is in the spirit of the original email :-)

Regards
Peter

"Thomas Lindgaard" <th****@it-snedkeren.BLACK_HOLE.dk> wrote in message
news:pa****************************@it-snedkeren.BLACK_HOLE.dk...
Hello

I am probably going to start a war now... but so be it :)

I just want to hear what all you guys who eat pythons for breakfast use
for python coding. Currently I use Kate, but I would really like an IDE
with debugger and a source browser (ie. one the I can use to browse
through modules etc. when looking for just the right curses stuff and such
- I am a newcomer to Python).

... and no, Emacs or Vi are not what I want :)

--
Mvh.
/Thomas

Jul 18 '05 #8

P: n/a
Thomas Lindgaard wrote:
Hello

I am probably going to start a war now... but so be it :)

I just want to hear what all you guys who eat pythons for breakfast use
for python coding. Currently I use Kate, but I would really like an IDE
with debugger and a source browser (ie. one the I can use to browse
through modules etc. when looking for just the right curses stuff and such
- I am a newcomer to Python).

... and no, Emacs or Vi are not what I want :)


If you don't mind "bleeding edge" software - pydev for Eclipse is coming
along. You can try it for yourself:

http://pydev.sourceforge.net/

Markus.
Jul 18 '05 #9

P: n/a
On Jul 14, 2004, at 6:22 PM, Peter Milliken wrote:
These are just some of the reasons I use Emacs. What features of *your*
editor attracted you? How does it help you with writing Python code
(the
intent after all of this news group :-)). Does your editor have a
feature
that I have not listed above and yet you consider it *essential* (or at
least very handy :-)) in your generation of Python code?


I develop on multiple platforms, but only have an OS X machine in my
office. My other systems are accessible via ssh, vnc and RemoteDesktop.

I use BBEdit, the venerable text editor for the Mac. Yeah, it has all
the usual stuff that many other editors have, but the one thing I find
indespensible (being lazy and all) is a plug-in called
'BBAutoComplete'. In a nutshell, it keeps track of *every* word you've
written in *every* open editor window, and will auto-complete
*anything*. Pressing its hotkey cycles through all potential matches,
starting with the most recent word that begins with what you've typed.

For a lazy person like me, it's amazingly valuable. I find myself
hitting the hotkey in other editors and even when composing mail
messages such as this. I even do a lot of my Visual FoxPro coding in
BBEdit now, even though it doesn't have syntax coloring for it.

___/
/
__/
/
____/
Ed Leafe
http://leafe.com/
http://dabodev.com/

Jul 18 '05 #10

P: n/a
>>>>> "Markus" == Markus Wankus <ma**************************@hotmail.com> writes:

Markus> If you don't mind "bleeding edge" software - pydev for
Markus> Eclipse is coming along. You can try it for yourself:

Markus> http://pydev.sourceforge.net/

Too bad pydev development seems to be stopping - the developer is
losing interest in the project (or at least that is what is said on
the project page). I tried it yesterday, it seems very promising
(though the debugger was very slow).

Eclipse is the only candidate worthy of replacing Emacs in the future,
so here's to hoping someone will adopt the pydev project at some
point.

--
Ville Vainio http://tinyurl.com/2prnb
Jul 18 '05 #11

P: n/a
>>>>> "Peter" == Peter Milliken <pe****@resmed.com.au> writes:

Peter> Let's not do the war thing :-) But perhaps an exchange of
Peter> information?

Peter> Me, I use Emacs - have done so for 20 years now with never
Peter> a regret. When I

I use Emacs as my main editor/mail/news too. Too bad Emacs seems to
lack the development energy these days to match the features of modern
IDEs. I'm mostly talking about features like robust code completion
for C++ - cedet doesn't cut it yet (though it'll hit 1.0 RSN), and
there just isn't enough developers to make it work hitchlessly. There
seems to be a resource shortage on xemacs side, and GNU emacs is,
well, too RMSic to do anything modern. Now they are integrating GTK,
which is a good sign of course ;-).

Lately I've been starting to hope that Eclipse project would take the
role of Ultimate Editor That Will Be Around Tomorrow - something which
you can expect to use 10 years from now. It has its shortcomings (big,
slow, Java), but it's the best we've got so far.

Peter> key sequences - but I don't like using mice and menus -
Peter> takes longer than

Yes, complete keyboard is a must for something you plan on using all
the time.

Peter> their personal use? For example the following comment is
Peter> made in another (later) thread:

Peter> "augment Leo's mind blowing qualities" - which means what?
Peter> :-) Other than the fact the writer likes Leo? :-)

As the author of the comment, I think I need to explain a bit. Leo is
mindblowing, not as an editor but as an intelligence management
platform. I could easily imagine project managers using it to organize
things. It seems to have endless usage possibilities, of which
programming (or text editing is only a fraction). Ed was talking about
implementing a multi-user editor, and I imagined it would be quite
sweet to have outlines there too, from team collaboration perspective.

Peter> code templates for where the coder must supply the
Peter> arguments. But I guess I am not big on "syntax completion"
Peter> - I haven't really used to the code since I wrote it,
Peter> although I do use ELSE itself extensively in writing my
Peter> Python code :-)

Syntax completion (or semantic completion, or "intellisense" - syntax
completion suggests insertion of code templates, which are simple in
python anyway) is very handy in multi-person projects, or projects
that have craploads of code written by other people - sdk developers,
various subcontractors, whatever. Maybe less so in Python - for some
reason Python code is usually more "direct" and elegant - but it would
help a lot. We need some kind of static type information to provide
intellisense for Python, though. It's just something that needs to be
standardized in the language level, so tool writers can proceed with
implementing the intellisense.

Peter> 4. User extendable using either Lisp or Python ( :-) ) -
Peter> (see the reference

Here I hope eclipse + jython will turn out to be the "preferred" way
to extend the platform. Maybe someday :-).

Peter> 8. "Free" - in this day of powerful editors that are
Peter> available for zero cost, why purchase one? Either shareware
Peter> or commercial?

Yes, this is a must. Free beer & speech. Eclipse seems to combine the
best of both worlds here - the platform is free, but companies can
sell plugins for money. That way you are not "trapped" and can hold on
to your editing habits, while using some commercial stuff for exta
functionality; it won't hurt if it's company money :-).

--
Ville Vainio http://tinyurl.com/2prnb
Jul 18 '05 #12

P: n/a
Hello,

Ville Vainio wrote:
Markus> If you don't mind "bleeding edge" software - pydev for
Markus> Eclipse is coming along. You can try it for yourself:

Markus> http://pydev.sourceforge.net/

Too bad pydev development seems to be stopping - the developer is
losing interest in the project (or at least that is what is said on
the project page). I tried it yesterday, it seems very promising
(though the debugger was very slow).


I think the project is very activ:

Activity Percentile (last week): 98.4802%

Last release:

pydev 0.5, the katzenmeyer kids July 12, 2004

if the developer is losing interest, he does it on a very hight level. :-)

bye by Wolfgang
Jul 18 '05 #13

P: n/a
On 2004-07-14, Thomas Lindgaard <th****@it-snedkeren.BLACK_HOLE.dk> wrote:
I just want to hear what all you guys who eat pythons for breakfast use
for python coding. Currently I use Kate, but I would really like an IDE
with debugger and a source browser (ie. one the I can use to browse
through modules etc. when looking for just the right curses stuff and such
- I am a newcomer to Python).


Kdevelop3?
boa-constructor?

--
Steve C. Lamb | I'm your priest, I'm your shrink, I'm your
PGP Key: 8B6E99C5 | main connection to the switchboard of souls.
-------------------------------+---------------------------------------------
Jul 18 '05 #14

P: n/a
>>>>> "Wolfgang" == Wolfgang Langner <wl@flexis.de> writes:

Wolfgang> I think the project is very activ:

Wolfgang> Activity Percentile (last week): 98.4802%

Wolfgang> Last release:

Wolfgang> pydev 0.5, the katzenmeyer kids July 12, 2004

Wolfgang> if the developer is losing interest, he does it on a
Wolfgang> very hight level. :-)

Apparently he's "finishing" it.

From http://pydev.sourceforge.net/ :

Future My plans for the future are:

- 0.5 will be a bug-fix release, I am sure there are a few, there has
been a lot of new code between 0.3 & 0.4.

- 1.0 will be an Eclipse 3.0 compatibility release. There are some new
debugger features like an environment tab that are cheap to implement,
and very useful.

And that's it. Over & out, off to new projects.

So if you like this tool, it'll be up to you to take it to where you
want it to be.

--
Ville Vainio http://tinyurl.com/2prnb
Jul 18 '05 #15

P: n/a
Personally I think its hard to look past Komodo these days:

a) very cheap (personal edition)

b) edits, debugs (locally and remotely, with all the debugging
features that you expect) and has projects

c) cross platform (you get licenses for both Win32 and Linux versions
automatically)

d) isnt Python specific (eg. works just as well for PHP)

e) a lot faster and more stable than it used to be (probably due to
its much improved underlying Mozilla code of late)

I've only really got 2 complaints with it:

a) No Brief keyboard mappings :-(
b) Cant inspect a variable by hovering the mouse above it when
debugging

I've also tried their VisualPython and didnt really think it was any
better, though a hell of a lot more expensive (and still no Brief
keyboard mappings).

Just my 2.6 australian cents
Jul 18 '05 #16

P: n/a
On Thu, 15 Jul 2004 07:37:19 +0000, Steve Lamb wrote:
Kdevelop3?


I've tried that - but does it have a debugger for Python? As far as I can
tell it only debugs C/C++.

--
Regards
/Thomas

Jul 18 '05 #17

P: n/a
On Thu, 15 Jul 2004 08:22:54 +1000, Peter Milliken wrote:
So whilst I know that Thomas does not "want Emacs or Vi", I believe my
response is in the spirit of the original email :-)


It is indeed :)

But I just think that I could ever learn all those keyboard shortcuts...
and I've tried a few times to install new modes (eg. PHP-mode) - sometimes
with success :) - but Emacs and I will never be best friends.

<war disregard="yes please do">
It's a great editor for yum.conf and the like, though.
</war>

--
Regards
/Thomas

Jul 18 '05 #18

P: n/a
On 15 Jul 2004 11:27:20 +0300,
Ville Vainio <vi***@spammers.com> wrote:
- 1.0 will be an Eclipse 3.0 compatibility release. There are some new
debugger features like an environment tab that are cheap to implement,
and very useful.
And that's it. Over & out, off to new projects.


It looks like I might begin working with Eclipse as part of my job,
developing plugins for our internal use. Having Python support would
therefore be useful; is anyone else interested in helping to maintain
Eclipse/Python support?

--amk
Jul 18 '05 #19

P: n/a
Ville Vainio wrote:
>>"Markus" == Markus Wankus <ma**************************@hotmail.com> writes:

Markus> If you don't mind "bleeding edge" software - pydev for
Markus> Eclipse is coming along. You can try it for yourself:

Markus> http://pydev.sourceforge.net/

Too bad pydev development seems to be stopping - the developer is
losing interest in the project (or at least that is what is said on
the project page). I tried it yesterday, it seems very promising
(though the debugger was very slow).

Eclipse is the only candidate worthy of replacing Emacs in the future,
so here's to hoping someone will adopt the pydev project at some
point.


I agree. I think there are a few other developers on the project that
will take over where Aleks leaves off. I will definitely get involved
in the future as time permits. I think this project will rock if we
could integrate jpype when it is ready (http://jpype.sourceforge.net/).

But you are correct - you do need some sort of type system in the
language to get all the features of the Java editor. You could do some
rudimentary stuff (like the way Pythonwin works for instance) right
away. The big thing we need is a *real* debugger - the editor stuff can
come later.
Seeing just how amazing Eclipse is for Java development makes me wonder
if the designers of Java had more than the language in mind when
developing it. Perhaps they were thinking ahead to the future of the
IDE they would use to develop the language....

Markus.
Jul 18 '05 #20

P: n/a
Markus Wankus wrote:
Ville Vainio wrote:
>>> "Markus" == Markus Wankus
>>> <ma**************************@hotmail.com> writes:


Markus> If you don't mind "bleeding edge" software - pydev for
Markus> Eclipse is coming along. You can try it for yourself:

Markus> http://pydev.sourceforge.net/

Too bad pydev development seems to be stopping - the developer is
losing interest in the project (or at least that is what is said on
the project page). I tried it yesterday, it seems very promising
(though the debugger was very slow).

Eclipse is the only candidate worthy of replacing Emacs in the future,
so here's to hoping someone will adopt the pydev project at some
point.


I agree. I think there are a few other developers on the project that
will take over where Aleks leaves off. I will definitely get involved
in the future as time permits. I think this project will rock if we
could integrate jpype when it is ready (http://jpype.sourceforge.net/).

But you are correct - you do need some sort of type system in the
language to get all the features of the Java editor. You could do some
rudimentary stuff (like the way Pythonwin works for instance) right
away. The big thing we need is a *real* debugger - the editor stuff can
come later.
Seeing just how amazing Eclipse is for Java development makes me wonder
if the designers of Java had more than the language in mind when
developing it. Perhaps they were thinking ahead to the future of the
IDE they would use to develop the language....

Markus.


Regarding JPype and Eclipse

Actually you are right. When I started JPype I immediatly saw where it
could help in eclipse. Let's face it, people interested in a Python
editor will not want to spend long hours coding it ... in Java.

I do not know how easy it will be to implement Eclipse plugins/extension
in Python, but I sure will try. :)

Steve Menard
Jul 18 '05 #21

P: n/a
Ville Vainio wrote:
>>"Wolfgang" == Wolfgang Langner <wl@flexis.de> writes:

Wolfgang> I think the project is very activ:
Wolfgang> pydev 0.5, the katzenmeyer kids July 12, 2004
Wolfgang> if the developer is losing interest, he does it on a
Wolfgang> very hight level. :-)

Apparently he's "finishing" it.

From http://pydev.sourceforge.net/ :
Future My plans for the future are:

[snip plans]

Actually, it's nice to see that the developer has an exit
strategy. Sounds like one of the more promising projects
on SourceForge from that statement alone... too many
people (myself included) start projects there without the
slightest plan for the future, including how to hand it off
when we get tired and need to move on.

Just because the one who initiated it has plans to leave,
at some not clearly defined point in the future, doesn't
mean the project will fail. It just means the fellow is
realistic and has good experience in open source dev...

-Peter
Jul 18 '05 #22

P: n/a
neblackcat wrote:
I've also tried their VisualPython and didnt really think it was
any better, though a hell of a lot more expensive (and still no
Brief keyboard mappings).


Zeus for Windows (shareware) has Brief emulation, is scriptable
using python macros and comes pre-configured for python, but as
the name suggests it only runs on the Windows platform:

http://www.zeusedit.com/lookmain.html

Jussi Jumppanen
Jul 18 '05 #23

P: n/a
el*****@my-deja.com wrote:
I agree. I've tried Komodo, Wing, and all the free ones, and Komodo is
far and away the most polished.

neblackcat wrote:
Personally I think its hard to look past Komodo these days:



I liked Komodo when I tried it too, but really wished that it had a
class browser. I asked the folks at ActiveState about that and they
said that it wasn't a planned addition at this time.

Unlike the earlier (and currently stable) version of Wing, Wing 2.0 beta
sports a lot of "polish". The IDE has been substantially rewritten,
using (I believe) the QT gui library (you can see the new look from the
screen shots on the wingware web site).

Jul 18 '05 #24

P: n/a
A.M. Kuchling wrote:
On 15 Jul 2004 11:27:20 +0300,
Ville Vainio <vi***@spammers.com> wrote:
- 1.0 will be an Eclipse 3.0 compatibility release. There are some new
debugger features like an environment tab that are cheap to implement,
and very useful.
And that's it. Over & out, off to new projects.

It looks like I might begin working with Eclipse as part of my job,
developing plugins for our internal use. Having Python support would
therefore be useful; is anyone else interested in helping to maintain
Eclipse/Python support?

--amk


I'd be up for it. I can totally sympathize with the developer of pydev
about the PITA that Eclipse can be - but you gotta admit there is a HUGE
amount of functionality there for free. I can say that because I've had
a relatively productive week developing Eclipse. Some weeks are worse
than others... ;o)

Markus.
Jul 18 '05 #25

P: n/a
Paul Morrow wrote:
Unlike the earlier (and currently stable) version of Wing, Wing 2.0 beta
sports a lot of "polish". The IDE has been substantially rewritten,
using (I believe) the QT gui library (you can see the new look from the
screen shots on the wingware web site).


I see some files with 'gtk' in their names in the install directory, so
maybe that's what they are using. If so I've never seen gtk look so good.

For you people with eclipse experience, does their gui toolkit wrap just
motif on linux (why oh why)? I wonder what the potential for developing
gui apps under eclipse with python is.

Stephem
Jul 18 '05 #26

P: n/a

Ville> Too bad Emacs seems to lack the development energy these days to
Ville> match the features of modern IDEs.

Dilution of the development community by the continued rift between the GNU
Emacs and XEmacs folks doesn't help...

Skip
Jul 18 '05 #27

P: n/a
Thomas Lindgaard <th****@it-snedkeren.BLACK_HOLE.dk> writes:
but Emacs and I will never be best friends.


That would require mutual respect. I love Emacs, but I often feel that it
barely tolerates me.

Nick

--
# sigmask || 0.2 || 20030107 || public domain || feed this to a python
print reduce(lambda x,y:x+chr(ord(y)-1),' Ojdl!Wbshjti!=obwAcboefstobudi/psh?')
Jul 18 '05 #28

P: n/a
ne********@yahoo.com.au (neblackcat) writes:
Personally I think its hard to look past Komodo these days:


I like Komodo a lot, but without an OS X version it's of limited use
to me.

(X)Emacs is still the winner -- runs on all platforms, and has a text
mode for the times I'm logged into a system through a terminal
emulator.

Nick

--
# sigmask || 0.2 || 20030107 || public domain || feed this to a python
print reduce(lambda x,y:x+chr(ord(y)-1),' Ojdl!Wbshjti!=obwAcboefstobudi/psh?')
Jul 18 '05 #29

P: n/a
On 16 Jul 2004 14:32:08 -0400, Nick Vargish <na*******@bandersnatch.org> wrote:
I like Komodo a lot, but without an OS X version it's of limited use
to me.

(X)Emacs is still the winner -- runs on all platforms, and has a text
mode for the times I'm logged into a system through a terminal
emulator.


Has anybody else conceded defeat there isn't a be-all, end-all text
editor for them? I've mostly just decided to look for an editor on
each platform that has the core functionality I want (key combos I
expect, code folding, etc.), but integrates well with the platform I'm
on. For example, I do mostly .NET work in Visual Studio at work. So
when I'm doing Python at work, it makes the most sense to use
ActiveState's Python add-in for VS.NET. When I'm on Linux, it might
be Komodo, or Eric3, or a stand-alone text editor.

I'd like to have a One True Editor, but in all my years of programming
(10 or so? :), I've never felt comfortable in either Emacs or Vi(m)

Shawn
Jul 18 '05 #30

P: n/a
On Fri, 16 Jul 2004 14:27:42 -0400, Nick Vargish wrote:
but Emacs and I will never be best friends.


That would require mutual respect. I love Emacs, but I often feel that it
barely tolerates me.


Heh :)

--
Mvh.
/Thomas

Jul 18 '05 #31

P: n/a
Thomas Lindgaard wrote:
On Fri, 16 Jul 2004 14:27:42 -0400, Nick Vargish wrote:

In this tread nobody mentioned Trolltech's Qt-Designer. Why?
Regards Lajos
Jul 18 '05 #32

P: n/a
Stephen Boulet wrote:
Paul Morrow wrote:
Unlike the earlier (and currently stable) version of Wing, Wing 2.0
beta sports a lot of "polish". The IDE has been substantially
rewritten, using (I believe) the QT gui library (you can see the new
look from the screen shots on the wingware web site).

I see some files with 'gtk' in their names in the install directory, so
maybe that's what they are using. If so I've never seen gtk look so good.

For you people with eclipse experience, does their gui toolkit wrap just
motif on linux (why oh why)? I wonder what the potential for developing
gui apps under eclipse with python is.

Stephem


Well, Eclipse uses SWT - which has binaries for each platform, and
various flavours of Linux, in particular there is a GTK2 version and a
Motif version. I don't know much about it - but here is what the
website says:
For Win32: Windows 98, ME, NT, 2000, and Server 2003; SWT HTML viewer requires Internet Explorer 5 (or higher). For GTK on other Linux systems: version 2.2.1 of the GTK+ widget toolkit and associated librares (GLib, Pango); SWT HTML viewer requires Mozilla 1.4GTK2. For Motif on other Linux systems: Open Motif 2.1 (included); SWT HTML viewer requires Mozilla 1.4GTK2.

An early access version of Eclipse is available for 64-bit Linux GTK. Testing has been limited to early access 64-bit J2SEs running on AMD64 processors.

SWT is also supported on the QNX Neutrino operating system, x86 processor, Photon window system, and IBM J9 VM version 2.0. Eclipse 3.0 on Windows or Linux can be used cross develop QNX applications. (Eclipse 3.0 is unavailable on QNX because there is currently no 1.4 J2SE for QNX.)

In terms of developing GUI apps - I think a SWT Python wrapper would
rule. It has a *very* similar feel to wxWidgets. The problem is there
is a small binary for each OS, but a big swt.jar file with most of the
platform-neutral code in it. I've played with Jython and SWT and used
Python to open up a Hello World window - but it definitely would not be
ready for a real app without some wrappers being written...

Markus.
Jul 18 '05 #33

P: n/a
Markus Wankus wrote:
Stephen Boulet wrote:
Paul Morrow wrote:
Unlike the earlier (and currently stable) version of Wing, Wing 2.0

.....

Have you ever heard of the Kompany's BlackAdder? I can't use it because
there is no GPL distribution (I'm retired and I've no money for software).
Lajos
Jul 18 '05 #34

P: n/a
Well, Eclipse uses SWT - which has binaries for each platform, and
various flavours of Linux, in particular there is a GTK2 version and a
Motif version. I don't know much about it - but here is what the
website says:
For Win32: Windows 98, ME, NT, 2000, and Server 2003; SWT HTML viewer
requires Internet Explorer 5 (or higher). For GTK on other Linux
systems: version 2.2.1 of the GTK+ widget toolkit and associated
librares (GLib, Pango); SWT HTML viewer requires Mozilla 1.4GTK2. For
Motif on other Linux systems: Open Motif 2.1 (included); SWT HTML
viewer requires Mozilla 1.4GTK2.

An early access version of Eclipse is available for 64-bit Linux GTK.
Testing has been limited to early access 64-bit J2SEs running on AMD64
processors.

SWT is also supported on the QNX Neutrino operating system, x86
processor, Photon window system, and IBM J9 VM version 2.0. Eclipse
3.0 on Windows or Linux can be used cross develop QNX applications.
(Eclipse 3.0 is unavailable on QNX because there is currently no 1.4
J2SE for QNX.)


In terms of developing GUI apps - I think a SWT Python wrapper would
rule. It has a *very* similar feel to wxWidgets. The problem is there
is a small binary for each OS, but a big swt.jar file with most of the
platform-neutral code in it. I've played with Jython and SWT and used
Python to open up a Hello World window - but it definitely would not be
ready for a real app without some wrappers being written...

Markus.


There is an alternative. If you want to use SWT with python, look at
http://jpype.sourceforge.net

Steve
Jul 18 '05 #35

P: n/a
Steve Menard wrote:
In terms of developing GUI apps - I think a SWT Python wrapper would
rule. It has a *very* similar feel to wxWidgets. The problem is
there is a small binary for each OS, but a big swt.jar file with most
of the platform-neutral code in it. I've played with Jython and SWT
and used Python to open up a Hello World window - but it definitely
would not be ready for a real app without some wrappers being written...

Markus.

There is an alternative. If you want to use SWT with python, look at
http://jpype.sourceforge.net


Cool... Not that it is an issue, but I assume you will have 2 JVM's
running (Java and Python) to do this?

Markus.
Jul 18 '05 #36

P: n/a
Markus Wankus wrote:
Steve Menard wrote:
In terms of developing GUI apps - I think a SWT Python wrapper would
rule. It has a *very* similar feel to wxWidgets. The problem is
there is a small binary for each OS, but a big swt.jar file with most
of the platform-neutral code in it. I've played with Jython and SWT
and used Python to open up a Hello World window - but it definitely
would not be ready for a real app without some wrappers being written...

Markus.


There is an alternative. If you want to use SWT with python, look at
http://jpype.sourceforge.net


Cool... Not that it is an issue, but I assume you will have 2 JVM's
running (Java and Python) to do this?


Ooops...obviously I meant 2 *VM*'s (not JVM's).

Markus
Jul 18 '05 #37

P: n/a
Skip Montanaro wrote:
Ville> Too bad Emacs seems to lack the development energy these days
to Ville> match the features of modern IDEs.

Dilution of the development community by the continued rift between
the GNU Emacs and XEmacs folks doesn't help...


not to mention they keep insisting on using lisp...

seriously, Emacs has the problem of increasingly large hurdles for its
users. I've been an Emacs users since 17.something and for many years,
I was carrying around my .Emacs file from place to place like a hobo's
bindlestiff. but in the past few years I've stopped. I just use
package defaults and default packages. It's become too
difficult to keep track of changes, update .emacs and replicate to the
10 or 15 machines (this month) that I'm using. Additionally, many
packages have become just too obnoxious to configure and use especially
with my limited hand ability. gnus and tramp have been the worst of
recent experience.

I do believe we could make this better by leading the way. I propose
reworking python mode using python via the Emacs python
extension. By lowering the barriers to entry, it's possible one could
rejuvenate development of applications within Emacs.

of course that doesn't solve the problem of propagating configuration
file changes to billions of machines but that's a different problem for
a different mailing list.

---eric

Jul 18 '05 #38

P: n/a
Markus Wankus wrote:
Markus Wankus wrote:
Steve Menard wrote:
In terms of developing GUI apps - I think a SWT Python wrapper would
rule. It has a *very* similar feel to wxWidgets. The problem is
there is a small binary for each OS, but a big swt.jar file with
most of the platform-neutral code in it. I've played with Jython
and SWT and used Python to open up a Hello World window - but it
definitely would not be ready for a real app without some wrappers
being written...

Markus.


There is an alternative. If you want to use SWT with python, look at
http://jpype.sourceforge.net


Cool... Not that it is an issue, but I assume you will have 2 JVM's
running (Java and Python) to do this?

Ooops...obviously I meant 2 *VM*'s (not JVM's).

Markus


hehe I was going to point it out ;)

And the asnwer is yes. I am embedding the JVM inside Python's. This is
a memory hit for sure, but Python's memory usage is pretty lean as it
is, and Java's is getting better.

Steve
Jul 18 '05 #39

P: n/a
Eric S. Johansson wrote:
Skip Montanaro wrote:
Ville> Too bad Emacs seems to lack the development energy these days
to Ville> match the features of modern IDEs.

Dilution of the development community by the continued rift between
the GNU Emacs and XEmacs folks doesn't help...

not to mention they keep insisting on using lisp...

seriously, Emacs has the problem of increasingly large hurdles for its
users. I've been an Emacs users since 17.something and for many years,
I was carrying around my .Emacs file from place to place like a hobo's
bindlestiff. but in the past few years I've stopped. I just use
package defaults and default packages. It's become too
difficult to keep track of changes, update .emacs and replicate to the
10 or 15 machines (this month) that I'm using. Additionally, many
packages have become just too obnoxious to configure and use especially
with my limited hand ability. gnus and tramp have been the worst of
recent experience.

I do believe we could make this better by leading the way. I propose
reworking python mode using python via the Emacs python
extension. By lowering the barriers to entry, it's possible one could
rejuvenate development of applications within Emacs.

of course that doesn't solve the problem of propagating configuration
file changes to billions of machines but that's a different problem for
a different mailing list.

---eric


Here's an idea : how hard would it be to replace emacs's ELIP
interpreter with Python, and translate the "main" ELISP modules to python?

I would love being able to use something like emacs and custimize it to
my hearts content. ELISP, however, just does not fit in my brain.

Steve
Jul 18 '05 #40

P: n/a
[Steve Menard]
Here's an idea : how hard would it be to replace emacs's ELISP
interpreter with Python, and translate the "main" ELISP modules to
python?
It would be a long and difficult task, in my opinion. One may also
consider writing an Emacs Lisp interpreter in Python for recycling bulks
of interesting Emacs Lisp modules or packages without translating them,
but this is also fairly daunting, pondering how to do this properly.

Just dream and suppose it was doable to translate things like Gnus (or
Calc) from Emacs Lisp to Python. It would not make them simpler to
learn nor to configure. The heaviness lies in the problem, not in the
language, so a change of language would not eradicate the heaviness.
I would love being able to use something like emacs and custimize it
to my hearts content. ELISP, however, just does not fit in my brain.


I did a great deal of Python customisation of Emacs, and also turned
many existing lines of Emacs Lisp into Python (for easier maintenance),
and finally, I got much more Python than Emacs Lisp customisation. I
used Pymacs for doing so, see http://pymacs.progiciels-bpi.ca (I think
the "official" URL is still http://www.iro.umontreal.ca/~pinard/pymacs).

An unexpected advantage, and I discovered this only later, appeared when
I switched from Emacs to Vim: all that Python code could be recycled
into Vim with a moderate effort. It could have been worse, for example,
if I had not been careful at well segregating, all along in my Python
code, the editor interface from the "algorithmic" parts.

--
François Pinard http://www.iro.umontreal.ca/~pinard
Jul 18 '05 #41

P: n/a
>>>>> "Francois" == François Pinard <pi****@iro.umontreal.ca> writes:

Francois> [Steve Menard]
Here's an idea : how hard would it be to replace emacs's ELISP
interpreter with Python, and translate the "main" ELISP modules to
python?


Francois> It would be a long and difficult task, in my opinion.
Francois> One may also consider writing an Emacs Lisp interpreter
Francois> in Python for recycling bulks of interesting Emacs Lisp
Francois> modules or packages without translating them, but this
Francois> is also fairly daunting, pondering how to do this
Francois> properly.

How about just reusing the elisp interpreter in its C form, wrapping
it as a python library and tweaking it enough to make it store all
objects in the python object space? GC would need to be replaced with
INCRED/DECREF, but other than that, shouldn't the implementation of a
Lisp interpteret be almost trivial?

Francois> Just dream and suppose it was doable to translate things
Francois> like Gnus (or Calc) from Emacs Lisp to Python. It would
Francois> not make them simpler to learn nor to configure. The
Francois> heaviness lies in the problem, not in the language, so a
Francois> change of language would not eradicate the heaviness.

Of course, that's why we would reuse those. New stuff (and hooks /
customization) could be implemented in Python. I imagine *many* more
people would be interested in improving, extending and maintaining
emacs if it was not in elisp; it's just not what kids want to use
anymore. The current slow pace of emacs development kinda makes it
obvious. Even the Common Lisp fans seem to dislike elisp.

Francois> An unexpected advantage, and I discovered this only
Francois> later, appeared when I switched from Emacs to Vim: all
Francois> that Python code could be recycled into Vim with a
Francois> moderate effort. It could have been worse, for example,

You switched from emacs to vim? That borders on blasphemy ;-).

Seriously, is Vim as customizable/programmable in python as emacs is
in elisp? If that is the case, I'm switching too...

--
Ville Vainio http://tinyurl.com/2prnb
Jul 18 '05 #42

P: n/a
On 20 Jul 2004 16:28:04 +0300,
Ville Vainio <vi***@spammers.com> wrote:
... GC would need to be replaced with INCRED/DECREF, but other than
that, shouldn't the implementation of a Lisp interpteret be almost
trivial?


Okay, I can't resist: That looks like the Quote of the Week to me.

Regards,
Dan

--
Dan Sommers
<http://www.tombstonezero.net/dan/>
Never play leapfrog with a unicorn.
Jul 18 '05 #43

P: n/a
Ville Vainio <vi***@spammers.com> wrote in message news:<du****************@amadeus.cc.tut.fi>...
How about just reusing the elisp interpreter in its C form


Given the Deep Magic emacs does during the build process, I'm not sure
how easy that would be. If I recall correctly, it builds a minimal
Lisp interpreter, uses that to run a bunch of Lisp code, and then
coredumps the running image into a new executable. Even if you could
sort that out, you still have the problem of figuring out how to wrap
all the Lisp objects with appropriate Python objects.
Jul 18 '05 #44

P: n/a
[Ville Vainio]
How about just reusing the elisp interpreter in its C form, wrapping
it as a python library and tweaking it enough to make it store all
objects in the python object space?
Go for it, then! :-)
Seriously, is Vim as customizable/programmable in python as emacs is
in elisp? If that is the case, I'm switching too...


Emacs Lisp is deeply soldered into Emacs internals. Vim has its own
language, which people sometimes call Vimscript, similarly tightened
into Vim. My feeling is that Emacs Lisp allows for a more intimate
handling of edit buffers and external processes than Vimscript does, yet
this intimacy has a price in complexity, so all totalled, they may be
perceived as comparable for most practical purposes.

Pymacs allows customising Emacs with Python instead of Emacs Lisp, and
then runs Python as a process external to Emacs, with a communication
protocol between both processes. Python may be built into Vim, and then
both Python and Vim use a single process. The same as Pymacs gives
access to almost all of Emacs Lisp, Python within Vim gives access to
almost all of Vimscript, but with a smaller overhead than Pymacs.

Pymacs is not Emacs Lisp, and Python in Vim is not Vimscript either,
tweaks are needed in both cases for accessing some of the underlying
scripting facilities. Pymacs is rather elegant, Python in Vim is rather
clean. Python itself is both elegant and clean, but one strong point of
Python for me is the legibility, which builds deeper roots on the clean
side than on the elegant side. All in all, despite I know how debatable
it can be, I guess I now have a prejudice towards Python in Vim.

--
François Pinard http://www.iro.umontreal.ca/~pinard
Jul 18 '05 #45

P: n/a
sj*******@yahoo.com (G. S. Hayes) writes:
How about just reusing the elisp interpreter in its C form
Given the Deep Magic emacs does during the build process, I'm not sure
how easy that would be. If I recall correctly, it builds a minimal
Lisp interpreter, uses that to run a bunch of Lisp code, and then
coredumps the running image into a new executable.


That step is optional and with current computers, it's not really
necessary. It was intended to avoid making Emacs spend time loading
the Lisp files for the standard editing functions every time you
started Emacs. On the old Vaxes, that could take over a minute,
especially when other users were sharing the cpu. But on a reasonable
workstation these days, it takes less than a second, so you don't
really need the unexec any more.
Even if you could sort that out, you still have the problem of
figuring out how to wrap all the Lisp objects with appropriate
Python objects.


I think writing some Lisp/Python hybrid interpreter is possible but
doing a direct translation of Emacs Lisp to Python isn't really feasible.
Jul 18 '05 #46

P: n/a
François Pinard <pi****@iro.umontreal.ca> writes:
Pymacs is not Emacs Lisp, and Python in Vim is not Vimscript either,
tweaks are needed in both cases for accessing some of the underlying
scripting facilities. Pymacs is rather elegant, Python in Vim is rather
clean.


What are these editors? Are they written in Python? How do they
implement the editing buffer? How do they implement searching
backwards for a regexp in the buffer?
Jul 18 '05 #47

P: n/a
[Paul Rubin]
[François Pinard]
Pymacs is not Emacs Lisp, and Python in Vim is not Vimscript either,
tweaks are needed in both cases for accessing some of the underlying
scripting facilities. Pymacs is rather elegant, Python in Vim is
rather clean.

What are these editors? Are they written in Python? How do they
implement the editing buffer? How do they implement searching
backwards for a regexp in the buffer?


Pymacs is just a add-on over Emacs, it is not an editor in itself, like
Emacs is. Pymacs is written half in Python, half in Emacs Lisp. Pymacs
allows Emacs to externally start a collaborating Python interpreter, and
be extended with Python instead of Emacs Lisp. The Python extension,
executed by the Python interpreter, handles editing by "asking" Emacs to
do the work. For example, it could call `lisp.buffer-substring()' to
get a copy of part of a buffer, massage that string in Python, and then
use both `lisp.delete()' and `lisp.insert()' to replace the original
text by the modified one. One normally writes `from Pymacs import lisp'
first, and the `lisp' object contains a lot of magic, including all
about the communication protocol.

Python in Vim is just a add-on over Vim, it is not an editor in itself,
like Vim is. Python in Vim is the full Python interpreter, written in
C, and linked right into Vim. Python in Vim allows Vim to be extended
with Python instead of Vimscript. The Python extension handles editing
by "directly" acting on `vim.current.buffer', which is a Python list
of buffer lines. One normally write `import vim' first, and the `vim'
module offers a lot of magic, provided by the Vim-Python integration.

Searching backwards for a regexp in the buffer? In both Pymacs and
Python in Vim, I would likely get Python to ask either Emacs, likely
through something like `lisp.regexp_search_backwards("REGEXP")', or Vim,
likely through something like `vim.command("normal ?REGEXP?")'.

--
François Pinard http://www.iro.umontreal.ca/~pinard
Jul 18 '05 #48

P: n/a
Paul Rubin <http://ph****@NOSPAM.invalid> wrote in message news:<7x************@ruckus.brouhaha.com>...
François Pinard <pi****@iro.umontreal.ca> writes:
Pymacs is not Emacs Lisp, and Python in Vim is not Vimscript either,
tweaks are needed in both cases for accessing some of the underlying
scripting facilities. Pymacs is rather elegant, Python in Vim is rather
clean.
What are these editors?


Emacs and vi are the two most common editors for serious programmers
in the Unix/Linux world; vim is the standard vi implementation used on
most Linux distributions (and is widely available on other platforms,
including other Unixes as well as Windows, Macintosh, Amiga, Vax,
etc). GNU Emacs is the standard emacs implementation used on most
Unix platforms that have any emacs implementation (and is widely
available on other platforms, probably all those listed above but
certainly Windows, Macintosh, and other Unixes). Other common vi
implementations include nvi (used by BSD) and vile, other common emacs
implementations include XEmacs (formerly Lucid Emacs) and jed.
Are they written in Python? How do they implement the editing buffer?
Vim is implemented in C, and supports at least 4 scripting languages
for extensions (vim, python, perl, and tcl); most larger extensions
are written in Perl or Python, though some are in vim's built-in
script.

Emacs is a hybrid C/elisp implementation (elisp being Emacs' dialect
of LISP) and normally extensions are written in elisp. Pymacs allows
writing extensions in python.
How do they implement searching backwards for a regexp in the buffer?


At what level? In vim, at the user or vimscript level:
?some_regex
At the python level, you can use:

import vim
current_buffer=vim.current.buffer

And then use the standard Python re to search current_buffer (a list
of lines) or otherwise edit current_buffer. And you can treat
current_buffer basically as you would expect:

current_buffer[0]="New" # Change first line to "New"
current_buffer[0:0]="New" # insert new first line "New"
del current_buffer[9] # delete 10th line of buffer
current_buffer.append("Last") # Append line "Last" to buffer

Inside of vim, ":help python" has more info on the Python interface.

Alternatively, you could execute a Vim command from the Python
interface:

import vim
vim.command("?some_regex\n") #The search-backward command a user
would run
Jul 18 '05 #49

P: n/a
Ville Vainio <vi***@spammers.com> wrote in message news:<du****************@amadeus.cc.tut.fi>...
You switched from emacs to vim? That borders on blasphemy ;-).

I did that too, after 4-5 years of Emacs. Modal editing works well
with my brain. :-)
Seriously, is Vim as customizable/programmable in python as emacs is
in elisp? If that is the case, I'm switching too...


No, it isn't. Emacs has many more output options; vim basically only
supports text (and some file selectors and menus). So you couldn't
do, for instance, a web browser with inline image support in vim.

But you can access all vim commands, define new user functions and
keymappings, edit the text, set marks, etc.

So basically, it's a fully customizable text environment, and people
have done mail readers and so on in vim/Python. Getting debuggers
running in subshells and such is possible too, but basically only for
line-oriented tasks (no full terminal emulation).

But the general consensus in the Vim community is that Vim should
remain an editor, not an environment, and it should obey the Do One
Thing Well philosophy. The Emacs community often views Emacs as their
OS, doing everything from reading news/mail to playing games to
surfing the web from Emacs (and oh, yeah, editing text too). So don't
expect to find anything as polished as GNUS out of the box for
Vim--but do expect a lot of people who know how to make vim and slrn
work together very well.

Getting anything graphical interacting with Vim in a meaningful way
would be right out, at least until someone convinces Braam to add a
few things (like adding an input fd with callback), and polling
periodically can't happen either (so e.g. mail readers can only check
for new mail when the user hits a key, not every 5 minutes) until that
happens.
Jul 18 '05 #50

This discussion thread is closed

Replies have been disabled for this discussion.