Wingide is a beautiful application

Claudio Grondi claudio.grondi at freenet.de
Sun Dec 18 20:40:10 CET 2005


sjdevnull at yahoo.com wrote:
> Claudio Grondi wrote:
> 
>>The only thing what makes a difference to me is, that Wing 'understands'
>>Python code what results in features not available elsewhere (e.g. go to
>>definition).
> 
> 
> This is something that pretty much any reasonable programming editor
> will get you.  Vim and emacs both do it.
> 
> I get the feeling that a ot of people working with heavy IDEs don't
> realize how capable vim/emacs are, so I'll give a brief rundown of what
> my Vim environment does for me.  (I do Python web development)--if you
> don't like the Vi keybindings, the Cream package is Vim that behaves
> like a regular modeless editor but with all of vim's power (and a nice
> embedded Python interpreter for writing extensions):

I have tried Vim already multiple times in the past and it had always 
problems. But what was in the past must not stay this way forever, so I 
have got the latest download at
 
http://heanet.dl.sourceforge.net/sourceforge/cream/cream-0-33-1-gvim-6-3-90-1.exe

and installed it loading my current Python file.

With [Strg]-[End] I went to the end of the file where I wanted to 
continue editing, but the syntax highlighting told me there is no code 
but only a comment. I checked it and found out, that Vim is apparently 
not able to do proper highlighting when jumping to the end of the file 
not going through other parts of the code before.
Going back to the point where triple quotes comment begun (quite in the 
middle of the file) and back to the end did the trick to get proper 
highlighting again.
Apparently Vim syntax highlighting analyses only the code it has already 
'seen' within the editing window. This is not what I expect from a 
mature editor.
I have stopped here, because I found this problem after three seconds of 
using it, so imagine how much other problems will become apparent after 
using it three hours, right?
Vim similar as Wing has no [View] menu entry one can use for changing 
the text appearance in any reasonable Windows program, so the ancient 
Unix/Linux is still there with the system font as default setting for 
displaying text... It looks as I were in a DOS box, not in a text editor 
on Windows.
Loading a 100 MByte large file into this editor which pretends to be 
able to edit files of any size results in an Error.
I was not able to find how to do rectangular select/paste and there was 
no code folding for Python script code available.

Sorry, also this time still valid: Vim on Windows "no thank's".

I was just waste of my time to try it out again.

Claudio

> 
> 1. Python syntax checking: as I'm typing along, if I input a syntax
> error then the line is immediately highlighted in red.  Useful for
> catching brainos like:
> if a=1:
> (which will highlight in red when I hit enter, point out that I need ==
> instead of =).
> 2. Normal tag-jump stuff: Ctrl-click on a function/method call (or
> class or whatever) will jump to the function/method/class definition
> (Ctrl-T works as well if you don't like clicking).  It keeps a stack of
> visited files so you can drill down through your call stack and then
> pop back up to where you came from.
> 3. Python class browsing stuff: A Class menu shows the parent and child
> classes of the one you're currently in, and all the methods of the
> current class; selecting any of the above jumps to the appropriate file
> and line.
> 4. Interactive documentation stuff: When I type an open-paren, it looks
> to see what the prior keyword is and displays help for it in the status
> line (preferring Python documentation, then docstrings, then comments
> before the function/method/class definition).  Even if there's no
> help/comments, it'll show the arguments that the function takes.  So
> if, say, I type:
> 
> cmp(
> 
> then the status line displays:
> 
> cmp(x, y) Compare the two objects X and Y and return an integer
> according to ...
> 
> If I hit F1 it'll show the full help text.  Often the arguments are
> enough, and I find the status-line display a lot less intrusive than
> many on-the-fly help systems I've seen.
> 
> 5. A client menu selects which client I want to work in (so, say, I get
> a bug report for Client A, I select them from the menu).  The Class
> menu and other functions respect this (if I'm in the generic Company
> class, the Class menu will list Client A's Company subclass before the
> subclasses of other companies; if I jump to the Company definition,
> it'll go to Company A's client-specific version).  It also restarts
> development httpd servers on the current machine running with conf
> files appropriate to that client.
> 6. Full version control integration, including side-by-side diff
> viewing/editing, etc
> 7. Editor control on uncaught errors; if I hit a web page on my
> development httpd and it throws an uncaught exception, my editor will
> jump to the line the exception occured at (preferring a location in the
> stack that's in a file I'm currently editing).and I'll have the stack
> trace in a scratch buffer if I want it, or as I jump up/down the stack
> it'll show relevant parts of the trace in the status line.
> 
> There's a lot I'm forgetting, but the basic point is that even "simple"
> text editors like vim can easily do a lot of Python-specific niceties
> for you (emacs is similarly capable).
> 




More information about the Python-list mailing list