I have a similarly hacked up Emacs environment and it's actually gotten to the point that I'm taking a hard look at IDEs again. Having all this functionality available in a single integrated package with a visual debugger thrown in is starting to look strangely appealing.
IMO, IDEs are better for almost everything, except for actual text editing. For that, vim and emacs are still the best (I prefer vim for plain text editing prowess, but emacs has a lot of other goodies which make it closer to an IDE, but still not as good).
I agree. If I'm just editing text, like an email or a readme or a blog post or a typical config file, I'd rather have a quick, lean, dedicated text editor. Some of these editor-as-IDE environments start to feel a little like an incredibly pimped-out Pinto though.
IMO, the problem isn't with "just editing a quick file" or not.
The problem is, IDEs are amazing for everything other than editing text. This includes editing source code, mind you. I find it much easier and funner to edit code in vim, since it has so many small things that make editing code much faster.
IDEs are generally much slower for the actual act of editing code than things like vim. They're just better because of everything else they do, which (sometimes) makes up for it.
Also, most people care a lot more about all the other things like code completion than they do about the small improvement you can get by editing in vim/emacs.
Define most people. Personally I spend the majority of my day editing text, so the small improvements are pretty important.
P.S. I have code completion, jump to file etc all working just fine in vim. On a codebase with 15000+ files, this is a hell of a lot faster in vim than it is in say, Eclipse.
I agree that this is true, if you have no desire to learn how Emacs and your chosen modes work. If you are willing to dig in, the ability to fix your tools with a simple C-M-x is indispensable, and is a feature that no IDE has.
Firstly, emacs is not a quick-start environment. If I want to get started in a new language, let's say Java, downloading Eclipse will make getting started with Java insanely easy. The same with C++ and Visual Studio. Compare with emacs, in which I have to spend time getting things to work. I'm not saying it's worse in the long run (although I suspect you can't beat Java on Eclipse), but the overhead every time I want to try something new is large.
But the biggest problem with emacs is the "project management" functionality. Emacs is designed to be "just an editor". To do the most simple thing, which is to define a project consisting of a few directories, and be able to move between those files, is very hard. Pick up many modern editors, and you can, with one command, point to a directory and have a project tree, a "jump to file", etc, all built for you. Not to mention the way they create makefiles automatically, do code-completion, create tag files so you can jump to a function by name, etc.
I can just list the number of things I didn't have to know about before starting emacs: makefiles, tag files, etc. Not having to worry about these kinds of things is the biggest feature emacs is lacking.
Makefiles are an acceptable barrier to entry. I've lost a lot of hair trying to figure out how to build huge Java projects that the developers just built inside their five-major-versions-old IDE. ("Oh, just build it by clicking the 'export to WAR' button and then copy the file to each production server." No.)
Considering how trivial it is to write an ant file to do the same thing, it's appalling that the IDEs don't just do this by default. How can you write a good application if you don't even know how to compile it?
But the biggest problem with Emacs is the "project management" functionality. Pick up many modern editors, and you can, with one command, point to a directory and have a project tree, a "jump to file", etc, all built for you.
Of course, Emacs' version is a lot more flexible. The user can hook it, so he gets a fresh project REPL the first time he visits a new project. Or, he can hook the eproject-after-save hook, and commit the changes to a "backup" git branch, so that he never has to worry about not being able to undo.
The idea behind Emacs is that it can do things that nobody else has ever done before, and it continually lives up to this expectation.
(Also, "this is too hard for beginners". OK. Then how did I learn Emacs?)
It's not that Emacs or vi are lacking the features of an IDE, is that they were not designed to be one. If you want to make vim or Emacs an IDE you can, but it is not easy.
yep, back when i had a job coding under windows, i used to use gvim for text file editing, but visual studio for compiling, debugging and the really good search utilities.
> Having all this functionality available in a single integrated package...
s/available/trapped/
s/integrated/monolithic/
;-)
I think IDEs are useful, yet they always make me think what a bad example of code reuse they are. Code reuse? Are you kidding? Much better rewriting each plugin with each IDE ;-)
EDIT: By "monolithic" I don't mean that IDEs are not modular; I mean you can't use their modules elsewhere.
Emacs and Vim are as good as the tools they can build upon, just like Eclipse is as good as available plugins. If you are going to develop in Erlang or Common Lisp, chances are Emacs is the best free IDE around (I don't know about Vim). It isn't so if you are going to develop in Java.
There is a lot of wheel reinventing in the Emacs and Vim's camps too, however. I just wanted to say that no matter how much code reuse is valued by developers, the tools they use the most are made with the less reusable pieces of software around.
I have a similarly hacked up IntelliJ environment (with IdeaVim and other things) and it's actually gotten to the point that I'm taking a hard look at Emacs again. Having all this functionality available in a single integrated package with a visual debugger thrown in is starting to look strangely appealing.
