It's just not a mouse-based IDE. Mouse clicking makes my hands hurt much faster than using the keyboard. I also find it annoying to switch from mouse<->keyboard, so I don't want a UI that relies on constant mousing.
Saying "Emacs can do whatever you want" is like saying "your computer can do anything you want." Sure it can, so long as you're willing to write the code to make it go. But my time is finite; I cannot be bothered to re-build environments that have already been implemented elsewhere.
Yes, I've used ctags and I've used etags. They tend to be interesting approximations but are never 100% reliable. They don't do a deep sematic analysis of my program. (For example, they don't understand C macros.) They don't update as I type.
The closest I've ever seen has been the "Semantic Bovinator" thingy. I have never managed to get it to run, nor has anybody I've seen try. You experience may be different, of course. (I realize that by posting this I'm inviting a raft of people to post and say "It works for me!" :) )
That said, I use vim for C, but I still use Eclipse for Java and C++/Qt.
Perhaps vim and emacs don't do everything you want. But also, perhaps you don't know their capabilities as well as you think you do?
SLIME has this in Emacs for Common Lisp and perhaps other languages that work with SLIME.
I'm on a non-multitasking phone now so you'll have to do the googling yourself.
We might use different technologies. I mostly write Objective-C, Ruby, Python, C, JavaScript, and recently some Objective-J and Erlang. Now and then I write Lisp (CL, Emacs), Scheme, Haskell, x86 assembly, and PHP. The only one of those I don't write in Emacs is Obj-C.
Other editors or IDEs may be better at certain tasks, just as Emacs has unparalleled Lisp support with SLIME. When there is clearly a best tool in one field then people tend to use that tool, if the payoff is worth it. Except for pg and a few others, people generally write Lisp in Emacs. I write Cocoa and Cocoa Touch apps in Xcode and IB. I'm pragmatic about it. But when I tried to use Eclipse for Mojo (webOS) because Palm recommended Eclipse + Mojo plugin, it ended up being more productive for me to extend an existing Mojo mode for Emacs[1] to have even more features[2] than the Eclipse plugin (or any of the others, Komodo, etc). Similarly if I were doing Java I would at least look into IntelliJ IDEA or Eclipse.
[1] http://www.emacswiki.org/emacs/MojoSdk and http://github.com/samsonjs/mojo.el
[2] http://www.webos-internals.org/wiki/Comparison_of_Editors (temporarily down)
It's true that some things are lacking, so it's too bad that whoever wrote the code that does your high-level syntactic analysis didn't make it independent enough that it could be used in other places than whatever IDE you were referring to.
Good keyboard navigation in an editor is valuable, and many IDEs have poor support for it. On this we can probably all agree.
But as I read it, the grandparent post was about functionality. Modern IDEs have a level of semantic awareness that generic editors like Emacs don't, at least not without a prohibitive amount of effort to implement it. As a text editor, Emacs is very powerful. As a code editor, it lacks support for even basic semantic analysis, which means such tricks as it does have are naive operations based on text matching. In a world where even entry-level IDEs have support for basic refactoring, auto-completion and code navigation, Emacs is the dinosaur that hasn't seen the asteroid yet: awesome raw power but completely unaware of the bigger picture.
Emacs may have a shallower understanding of languages than an IDE, but the breadth of languages it understands is pretty amazing.
Still, I think this raises an interesting question: is it more beneficial to choose exactly the right language for each project in isolation, or to adopt a "good enough" general purpose language that can be learned in more depth by the development team, and used together with comprehensive library support and a strong and familiar IDE?
Eclipse is a step in the right direction in terms of openness and universality. But the editing experience still sucks. And it's harder to extend and customize than it should be.
There may come a day when there's an IDE that a) has a great editing experience b) is fast, flexible, and universal, and c) offer not just crutches and marginal improvements, but radical, order-of-magnitude improvements to the way we interact with software. It's not today. But the linked research project actually has some promise.
Are you sure? I would expect that the process of physically typing in the changes you want to make takes only a fairly small amount of time, certainly much less than understanding the code that will be changed or designing the new part.
However, the typing is just mechanical grunt-work that tends to distract from other areas. If it can be automated with good refactoring tools and the like and so minimize the distraction to the developer's thought process then so much the better.
I would really like to see Yi step up at some point and solve the problem here. It's already got proper incremental parsing with a proper syntax tree. When people add advanced language-specific modes to it, it might be the first "proper" refactoring vim/emacs like text-only IDE.
Not strictly speaking true: http://cedet.sourceforge.net/semantic.shtml
Um no. But if so, then someone better start busting a lisp to get emacs to make cute little bubbles. I'd love to see that.