[wingide-users] Re: Are there any hardcore vim/emacs user who have converted to wing?

[Mitchell L Model]

> Date: Thu, 17 Dec 2009 03:16:21 -0800 (PST)
> From: ryan heniser <heniser at yahoo.com>
> Subject: [wingide-users] Are there any hardcore vim/emacs user who
> 	have	converted to wing?
> To: wingide-users at wingware.com
> Message-ID: <752266.56426.qm at web52808.mail.re2.yahoo.com>
> Content-Type: text/plain; charset=us-ascii
>
> I'm a hardcore vim user. It's taken me years to memorize the  
> keystrokes and get my vim just right. But, auto complete in vim on  
> python code is not the best and the svn & cvs integration requires  
> yet another dozen key strokes to memorize.
>
> I'm about to give wing ide a test drive. I'd love to hear from any  
> other x hardcore vim/emacs users who have made the switch.

I am an Emacs super-wizard. I've used it extensively for 30 years. I  
worked in the Lisp world for a long time and write enormous amounts of  
ELisp functions. I am also a keybinding maniac, one of those people  
who can remember combinations like control-alt-shift-leftelbow. I bind  
everything I use more than once a month. I also write ELisp macros for  
just about anything I do more than a few times.

Strangely, I am also a Mac fanatic, having used them since I bought my  
first 128K Mac in 1984, and a lot of my professional life involves  
software development tools and user interfaces, so I am well aware of  
the archaic aspects of Emacs in that respect.

I write a lot of code in a lot of languages for courses I write and  
teach (both academic and professional) and for the two books I've  
published, a C++ Data Structures book and a just-published O'Reilly  
book called Bioinformatics Programming Using Python. I also write a  
lot of code to automate my own work -- like in Emacs, but on a larger  
scale. I use several different keystroke-macro sort of programs on my  
Mac (these days its QuicKeys and Butler, with some help from Mac's  
System Preferences keybinding capabilities). I write a lot of  
AppleScript code. I'm saying all this because of the context it  
establishes, and I'll get to Wing in a moment.

I use Emacs for almost all my programming primarily because I write  
many small pieces of code or programs and the overhead and mental  
burden of using an IDE like Wing or Eclipse or any of the others isn't  
worth it for these purposes. However, when, as currently, I am working  
on a significant Python project, I am using Wing. The advantages of an  
INTEGRATED development environment should be obvious, but even there,  
Emacs isn't so bad. Where IDEs fall short is primarily in their  
limited editing facilities and their imposition of an "order of  
things" -- keybindings, menu contents, window component organization,  
etc. Assuming an IDE provides the tools one wants and does so in a way  
one finds comfortable, what for me are the subsurface capabilities  
needed for an IDE to be a powerful tool for an engaged professional  
rather than something that is obviously useful but not sufficiently  
comfortable or adjustable to use:

1. Change and add keybindings
2. Define additional commands based on existing commands
3. Modify menus (importance varies with the IDE and the kind of work  
being done)
4. Work well with major external packages such as cross-platform GUI  
toolkits, web frameworks, content management systems, etc.
5. Sufficient "awareness" (built-in API or commands in a scripting  
language) of the components of a program, at all levels: package,  
module, definition, statement, expression, identifier, etc.  
(corresponding to a text editor's awareness of documents, sections,  
paragraphs, sentences, words, etc.), with commands such as move  
forward/backward, select, delete, evaluate, etc. for each.
6. True integration of source and debugger so that one can evaluate  
source code from inside the debugger (a very powerful development  
style few languages and IDEs support is to put a break at a point in  
your code where you don't understand the state of things or what you  
want to do there, get into the debugger, look at the values of the  
local variables, etc. and try out pieces of code right there, adding  
them to your source code, then continuing).
7. Compatibility in look and feel, clipboard behavior, menus,  
keybindings, etc. with the host platform.

Emacs is spectacular in most of these areas. (It takes a while to  
figure out how to use an interactive Python window in conjunction with  
pdb and your Python code, but Emacs has a cross-language uniform  
interpreter/debugger interface that makes the effort worthwhile -- or  
very small if you are already using it for another language.) That  
doesn't mean that moderate Emacs users take advantage of all of this,  
of course.

So, what about Wing? Wing is exceptionally strong in all of these  
areas, except that it's a little weak on 5 and, on a Mac, 7 (because  
it runs under X11 and there isn't much else left that needs to). What  
I do a lot is look for a Wing command that does what I know how to do  
in Emacs, and because it has a somewhat similar model, I often find  
it. When I don't I can script it. (It is well worth getting over the  
small hurdle of learning how to add commands to your environment.)  
Wing even distinguishes between keyboard and keypad keys (e.g.,  
command-0 and command-keypad-0) -- it doesn't impose very limiting  
restrictions on what keystrokes can be bound. Most importantly for  
people moving from another editor are the keyboard compatibility modes  
-- you can tell it to use vi or Emacs (or even Brief and a few other  
blasts from the past) bindings. Or native bindings. My biggest trouble  
right now is that I keep switching between Emacs and Mac OS X, and I  
am going to resolve that by just binding a large set of my own keys.  
(You don't have to use the preferences dialog for that -- you can  
simply edit your .wingide/preferences file: once you've done a few  
through the dialog, you'll see how that works.)

So to add to my list above, there really should be:

0. Supports the transition from other well-known editors by providing  
compatibility modes

And a warning: switching editors or IDEs or GUI toolkits or operatings  
systems, etc., is NEVER comfortable. One of the worst feelings a  
professional software developer can have is to move into a new  
language, new GUI library, new OS (even new version of the same OS),  
new IDEm and especially, new editor. You just feel like a clumsy  
idiot, and it's hard not to criticize the new world you have entered.  
It may be better, worse, or the same -- most likely it's a mixture --  
but you can't tell until you've gotten somewhat comfortable in it. And  
during the transition, whenever you come across a barrier that you  
"can't believe" -- something huge that appears to be missing,  
something you can't do, something you have to do, whatever -- ASK  
rather than just writing off the new environment. (You'll see some of  
my questions to this list and to other mailing lists I occasionally  
post questions to phrased something like "What am I missing here? I  
want to do this thing that seems really basic or important, and I just  
can't see how to do it. Surely it is there somewhere."

Oh, one more thing about Wing: you don't have to give up your external  
editor! It watches files in your current project and updates them as  
soon as they are saved from somewhere else. I move fast, and if I  
can't see how to do something in Wing and don't feel like taking the  
time at the moment to work it out, or need to do something that I'm  
pretty sure Emacs would do better, I just pop over to Emacs and edit  
the files there, then go back to Wing to continue working. Best of  
both worlds and a good way to make the transition. (See section 4.15  
of the documentation and the Files|Reload pane of the preferences  
dialog.) (The reloading process also works for generated files -- for  
instance, I am using Qt's Qt Designer to layout complicated GUIs then  
generating the corresponding Python code with PyQt's pyuicc4. If I  
have the generated file open in Wing, it changes as soon as I generate  
the new version. Very important.)


I am sure that once I dispatch this message I will think of more to  
say, or things I shouldn't have said, but informally, this is about