I was watching a presentation and someone was talking about integrating gdb with Emacs and showed a screenshot of it in action. I was at the back of the room and I had to squint, because when i first saw it, I swore it was Eclipse.
In this day in age of Eclipse having every feature of Emacs, save a good scripting and keystroke record/playback story, why would anyone still be using Emacs?
Well, of course, you'd be foolish to think that everyone using Emacs is just going to drop it and jump on the Eclipse bandwagon. And there are still some major technical hurdles that force you to be sympathetic with them.
And this is the challenge we face, especially in the technical and embedded space where the CDT is most popular. Eclipse is too big, too slow to start, and the UI too complex and unless we start addressing some of this, it's still going to be a fight to get these users to buy into our story. There is a lot of value to the extensibility and integration story we are selling, but if the barrier to get Joe and Jane developer to even start the thing is too high, it's no good.
With all the talk about e4 and new architectures for the new world going on, we also really need to take a long look at how we can finally beat Emacs. Yes, I'm CDT Doug, but I still use XEmacs on Windows as my main text editor, even to look at C++ files outside of workspaces. I shouldn't have to, you'd think...
I still use a medley of text editors outside Eclipse... vi (console editing w/ regex f&r), leafpad (plain text editor) and kate (split pane editor w/ regex f&r). They all have their strengths, and they're all lighter than Eclipse. But then for heavy string manipulation (eg., f&r in a lot of files) it's Eclipse FTW every time.
ReplyDeleteMeanwhile, there are at least two vi/vim plugins for Eclipse -- I'd be surprised if the same didn't exist for the Emacs folks.
I've tried to get a few Emacs users to look at Eclipse. The problem in my experience, is that most of them are happy with Emacs and not looking for something "better". It would be like asking you or me to try NetBeans. Maybe it does some things better and some worse, but I am not really looking for something better than Eclipse.
ReplyDeleteThree reasons that I know of:
ReplyDelete- Eclipse doesn't work well with unknown file formats/extensions.
- Eclipse can't open files outside the workspace.
- Workspaces are very difficult for less organized, real-world projects (nested dependencies, etc). Importing existing code into workspaces is *much* harder than it has to be.
Until workspaces are fixed (maybe Eclipse could just use nested project files like everybody else, dunno?), I don't think Eclipse can possibly be a good general-purpose text editor.
And, given the lack of progress in 3.3 and 3.4, it doesn't look like workspaces will be fixed in the next five years. :(
A boss of mine, a professor in applied mathematics, had a look today to my elipse session and said: Wrong editor, wrong language - Best is still FORTRAN and vi.
ReplyDeleteWell, I said "no comment" to him.
BTW, I could convince most of my collegues to switch from xemacs to Eclipse. It's just the vi guys how persist.
Responsiveness, keyboard navigation (yes, Eclipse has decent keyboard navigation but sometimes focus is in the wrong place, etc.), scriptability, UI consistency, ease of extension and customization, ability to easily execute arbitrary commands and import their output, project/workspace structure brittlness, natures (!), etc, etc.
ReplyDeleteI am from the hardware world. We love Emacs. Why? Because we do not not have anything useful for VHDL/Verilog in Eclipse. The Emacs key binding in Eclipse is not good enough yet. And even in Emacs, all we have is the modest verilog-mode to do basic productivity enhancement... we could do tons more. For example, most of hardware engineers do not even know what refactoring is... we have to manually do lot of it. If someone could help create a HDL plugin for Verilog, it would be awesome.
ReplyDeleteThere is lot of opportunity for Eclipse to make a difference to hardware design work. But people who can code Java don't know what to build and those who do, can't do Java :)
Hi Doug
ReplyDeleteLooks like you really struck a chord here. :-)
It's funny that Emacs users are complaining that Eclipse is too heavyweight. ;-)
But, for a lot of things it is.
I still want proper scripting and keyboard-recordable macros. And if we could just `eclipse somefile.blah` from the command line and have Eclipse Do The Right Thing, that would be nice too.
But that's (partly) why we're doing E4, right?
Realistically, I don't think Eclipse will ever replace lighter-weight text editors. For straight text editing, I use both VIM and Emacs: VIM for small config files like /etc/profile and Emacs for programs and scripts when I don't want to fire up a full-blown IDE.
Yes, I think we can address bringing up Eclipse just like we do Emacs with the flexible resource model work that we doing for e4. 'eclipse blah.cpp' is definitely in reach.
ReplyDeleteAnd we need to focus on the workflows where Emacs works better.
What I don't have an answer for is the startup time when you do that. There's been a lot of work to try and address it but it's going to take something in the JVM space to fix it.
But one thing people forget or don't realize, Emacs takes non-zero time to start up too...
Eclipse is (relatively) light-wight
ReplyDeleteif I compare it to my favourite (commerical) XML-plugin (oxygen).
This is like editor->eclipse.
Oxygen is rather slow (I have 4*2.8 GHZ cores and 1.5 GB VM-space) but the productivity gain by working based on our own schema files is huge. I can even code
simple XSL-templates without knowing the
language - just by the assistent.
Good points.
ReplyDeleteScriptability and flexible workspaces would be a huge leap towards the total Eclipse:)
But the main reason I'm still switching to Emacs is for keyboard macros.
As I found, even some Emacs users (let alone the rest of the world) don't realize how handy this is for repetitive text manipulation.
And that's a fairly common use case for refactoring. Much more powerful that Search&Replace and the built in Refactoring support - which is somewhat limited IMHO.
Being both an Emacs and an Eclipse user, my observation is that Emacs is for when you want a great text editor and Eclipse is for when you want a great model editor. If you are able to keep the entire model of your program in your head and just want to manipulate it as text, Emacs wins. If you are working on larger programs, with a team, multi-tasking, etc., then Eclipse's behind the scenes model of the program (semantics aware browsing, refactoring, visual debugging, etc) is the win.
ReplyDeleteThe real problem is that we're having a hard time getting customers to use Eclipse at all, which makes it hard to sell them on the value add, which of course impacts the bottom line.
ReplyDeleteUnfortunately our customers are very smart and can handle the model in their heads, and are happy just using a text editor for all their development. We need Eclipse to be a good text editor to get into their environment at all.
I am an emacs user since 1986. And I still use emacs. Mostly because of its macro recording capabilities.
ReplyDeleteThe arguments against eclipse are the same arguments emacs had 20 years ago:
EMACS is too big, too slow to start, and the UI too complex ....
One acronym was of eclipse was Eight Megabytes And Constantly Swapping (At a time when 8Mb was a lot).
One thing emacs did to speed up the startup is the use of undump: all modules are loaded and then emacs creates a core dump. At startup it loads the core back in memory and starts from there. Something like this could speed up the start of eclipse as well...
Emacs and eclipse are both expert tools. Both have very unique weird ways of user interaction. Once you are used to the paradigms it all feels natural. But if you see it for the first time you are lost.
I don't think that better usability in the classical sense will convince emacs users to switch to eclipse.
The problem is that the "experience transfer" from emacs (vi, visual studio or whatever) does not work. Being an emacs expert you are suddenly a eclipse beginner. And unless eclipse *is* emacs this pain will remain. And since there are so many migration paths to eclipse it is impossible to make them smooth for all.
Making eclipse like emacs or visual studio does not help much, because too many mixed concepts are very hard to understand.
To much choice makes usage and decisions hard.
Therefore I think eclipse should reduce the number of concepts. Making eclipse like emacs and visual studio and netbeens etc is the wrong way.
Thanks, Michael, I couldn't agree more. What bugged me most about the emacs discussion I was in was that somehow emacs appeals more to command-line junkies. That's crap. Emacs is as much an IDE as Eclipse is (give or take), and heavy weight in it's own right.
ReplyDeleteAnd yes, making Eclipse the same as emacs doesn't work, but I think there are a few things we can do to make the workflows a little easier, like being able to launch to edit a single file without having to create a workspace (or using a default workspace that encompasses the whole file system, or something).
Doug, no question we could learn from emacs! Like editor macro (keyboard) recording. But when we improve usability should do it the eclipse way....
ReplyDelete20 years ago I worked from home some times and I had only a 9600baud modem connection to the institute I was working at. Once I was logged into the remote machine (using a vt100 emulator on an atari) I started emacs and I never left it. I used it as IDE, news reader, email client, ftp client, shell, file browser and from time to time as editor. Emacs integrated everything I needed in the command line/vt100 world.
Eclipse is becoming more and more the integration platform for classical UI applications. I tend to do more and more things from within eclipse: remote work using RSE, ssh using the terminal, editing, sometimes for web browsing and reading rss feeds (with jazz)....
In the not too far future I could use eclipse as my "window-system" the same way I could have used emacs as my "log-in-shell"...
The funny thing is that Martin Fowler said once that Eclipse is the 21st century Emacs :)
ReplyDeleteI'm a long time emacs user and eclipse convert. First off, working on large projects in Java with Eclipse is just an entirely different animal than anything you can do in emacs, for serious programming I don't see myself going back to just emacs, ever. I guess there are three reasons I hold on to emacs, 1) I still do a lot of console stuff. 2) Keyboard macros. 3) I still need a general purpose editor and there isn't really a reason eclipse couldn't do it or be it, but it's not. I can fire up a remarkable number of files in emacs and it will identify them if it can, syntax high-light them, perhaps have some indentation intelligence and then let me go to town on them. In eclipse, if you fire up a file eclipse knows about it can often do a great deal more but it knows fewer of them. There have been a handful of plugins that attempt to provide that “general purpose” editor kind of functionality but they seem to get abandoned quickly. Often, I just want to open a file, not in any project, beat it with the edit stick and move on, I don't need auto-complete and the outline and some of the other fancy things but I do like the colors; it's a somewhat stupid request in the context of what eclipse does.
ReplyDeleteI have a soft spot in my heart for Emacs, in fact I choose to use the Emacs keybindings in Eclipse partially due to this affection. I have often said that the only problem with Emacs is the Lisp, meaning that the ability to configure and modify it's functionality is superb, but not too many of us want to write in Lisp. Still on occasion from a terminal access on a machine, I will use Emacs as a poor man's X-windows. It still surprises me how well that works.
ReplyDeleteDoug you bring out two of the main shortcomings of Eclipse compared to Emacs, scripting and playback. I have never used Emacs playback, but the scripting part I am familiar with. In fact, Eclipse today has that ability, take a look at Groovy Monkey, not Eclipse Monkey. Groovy Monkey is a full featured scripting tool for the Eclipse RCP/Platform/SDK. Hopefully after I get a chance to restart Eclipse Monkey, it will gain the same functionality.
Thanks, jervin. I'm hearing more and more about the need for Eclipse scripting. I don't get the whole "Monkey" thing but if it gets us scripting, the it's all good.
ReplyDeleteThanks for the reply Doug. I should have realized by now that not everyone knows from where the 'monkey' term comes from. 'Monkey' in Eclipse and Groovy Monkey is inspired by the Firefox extension 'Greasemonkey', which has to be the coolest of all Firefox extensions. The point to Greasemonkey is to allow a user to customize their browser view for certain web sites via a script and not a full Firefox extension (read plugin). My favorite is 'Better GMail' for instance.
ReplyDeleteSo how does this apply to Eclipse? Well Groovy Monkey, and in the near future Eclipse Monkey, is all about letting you script things for Eclipse. Want to write a macro that ties several Eclipse functions together? No problem, write a script. Want to know what that part of the Eclipse API is really doing? No problem, write a script. In fact, as a quick aside, you can imagine using the new Eclipse plugin spy, for 3.4 only, to find the code you want to use and then writing a monkey script to utilize it. So 'monkey' == 'scripting'.
I could go on and on, but that would be rambling. You know the kind of wild rambling a proud parent does about his child. I want to mention one thing more though, I like to preface my presentations about Groovy/Eclipse Monkey with the phrase, "With Groovy Monkey Eclipse finally catches up with Emacs."
I'm an old-time emacs/xemacs user. I started using eclipse within the last year to do java development, since it seemed like the natural choice for that. And it is great for that. What irritates me is that there is apparently no good way to edit text, such as comments or txt docs. Where is M-x auto-fill-mode? Or fill-paragraph?! I remember editing text in vi 20 years ago and hating having to re-fill a paragraph manually after inserting something in the middle. Do people create arbitrarily long lines of text in eclipse? Is it passe to hit enter at column 78 these days? This quibble alone is enough to make me edit text in emacs. That and the fact that eclipse doesn't perfectly map emacs keybindings. Stupid fingers won't learn new tricks....
ReplyDelete(If there is a way to fill-paragraph, etc., I'd be happy to hear it! I'm still an eclipse newbie, after all....)
>> With all the talk about e4 and new architectures for the new world going on, we also really need to take a long look at how we can finally beat Emacs.
ReplyDeleteThis is misguided and you need to think about this differently.
Eclipse is like a fantastic and evolving bread machine. Emacs is more like a pair of hands. Sure, you can make bread by hand, and some people love to do it that way. Yet, the perfect bread machine solves many practical problems. Bread machine makers would be remiss to consider hands their competition.
While it's a corny metaphor, I think it's applicable and worth considering.
Emacs is an extensible environment for manipulating text. Not a programming environment. The fact that Emacs has been considered a programming environment is a testimony to just how good it is at at its primary function. Yet programs, process interactions with debuggers, lists of classes and hierarchical models as programs, debugging streams... these things are basically text interactions, so for the most part, Emacs, being the ultimate tool for skilled hands which edit text, can do these things quite well.
Sure, you can claim that James Gosling and Richard Stallman were building programming editors. However, what they did, in the long run, is examined the activities involved in programming and decided that extensible text management was a better tool than something with the singular purpose of facilitating the development of modular programs.
The list of things Emacs can do which Eclipse cannot is monumental, but maybe mostly irrelevant to those developing Eclipse. I have used Emacs for 30 years. In that time I have watched as somebody used Emacs keyboard macros to through 1800 pages of TeX code for their manuscript and changed the way trademarks were handled in attributions (in under 20 minutes). I have seen people model recursive algorithms in Scheme in one buffer while they were using those models to determine why an enormous system built in C was failing to produce the modelled results. I have seen people do a "find-file" on the Linux kernel and patch a section of the binary using Control-Q and overwrite mode to enable a hidden feature. I have a great elisp poetry analyzer, and a variation on etags that does amazing things to create an interwoven network of variable naming conventions so I can use them consistently across hundreds of modules to assure that people who read the code will see similar styles and not "the style of the day".
It would be better for Eclipse to consider the kinds of activities Emacs users can't live without when programming (like keyboard macros that can do anything). It's better to figure out where to draw the line, and what to emulate and what not to, and how to deal with the limiations that a limited-purpose environment has when compared to an environment that has fewer limits.
People will be using Emacs for a long, long time because of its versatility. Once you master it, there are things which can be done so fast that you simply cannot find a better way. But, those who master Emacs will, increasingly, be in the minority as the number of software people continually grows. Eclipse can do a better job for the majority. But you have to not look at it as a battle.
I don't make bread with my hands anymore. It's hard work, and I never really did master creating clever french rolls and pastries. I have a very good bread machine which does what I need. But Panasonic and Sanyo would surely be heading in the wrong direction if they were trying to figure out how to put hands out of business.
I'm six months late to the conversation, but six months ago I didn't use Eclipse at all (it was too slow on my old hardware and I am not a Java programmer.) Let me say that Eclipse impresses the heck out of me. I love the help system and the ability of a plugin like PyDev to be able find the definition of a class or instance in a dynamic language is incredible. And the refactoring capabilities blow my mind.
ReplyDeleteMost of what I have to say has been covered, but as a long time emacs user here are the reasons I keep going back to emacs (I apologize if Eclipse handles any of these, as I am just learning it):
1. I'm familiar with it. I'm trying to get my work done and I know how to do that in Emacs. Sad but true.
2. Keyboard record and playing back and macros. I am not a power Emacs user, but I can do crazy things very quickly.
3. Modes, especially minor modes like auto-fill (I'm old school and hate 250 character lines, thank you very much.)
4. If emacs guesses wrong, e.g. doesn't recognize a shell script, I can change the mode of the buffer without opening a new editor.
5. The ability to include mode and other information in the "comments" of the text file itself. This can mostly be worked around with Eclipse file-type/content preferences but that requires configuring Eclipse rather than just being conveyed in the file in question.
6. I don't have to use a mouse. Ever. (Maybe I just haven't learned the right keys, but with M-X may I can use the keyboard to tell Emacs to perform actions that are not bound to the keyboard.)
7. M-x grep: I can pipe together a crazy series of commands that result in grep-like output and emacs will parse the output in a buffer I can scan and then selected only the lines that look useful (rather than going next, next, next through a 1000 matches).
8. I find tab-completion for file and buffer names with history is super efficient for opening files and buffers. When you have a hundred files of different types open it's hard to beat ^X^B.
9. The emacs key-bindings where close enough to mostly confuse me. (Hey, I'm easily confused.)
10. But in the end what kills it for me every time is there will be some file I want to open that is not part of the "workspace." To do so I need to open another editor and that drives me nuts. (Especially given the above M-x grep tricks).
Hi, I am curious if there is any work on getting CDT integrated with Emacs. I don't think I will ever use Eclipse because I normally code with command line Emacs over SSH to various machines. Plus I really like not using the mouse at all.
ReplyDeleteI develop in C/C++ and I would love to use CDT. The alternative in Emacs is cscope, wich is very imprecise for C++.
Any thoughts if the Emacs CDT integration is feasible?
Thanks
Anything's feasible. But Emacs and CDT together his highly unlikely. CDT works well because it's Eclipse.
ReplyDeleteWell, many years ago we had an integration of our C/C++ IDE SNiFF+ with emacs: there was a socket connection between SNiFF+ and emacs. SNiFF+ was sending the syntax highlight etc to emacs and we exposed lots of commands to emacs that would then send it to SNiFF+.
ReplyDeleteThat was not a 100% integration but good enough that many people used it. Something like that could be done with CDT by an emacs-CDT enthusiast...
I use VI and Emacs. And I tried Eclipse during a whole week. Here is my wish list for Eclipse:
ReplyDelete1) I don't want to download and install a large virtual machine. I want a native Eclipse. The Eclipse distribution should not be larger than Emacs distribution: 50 Megabytes, virtual machine included.
2) I want to do my scripting in LISP. It is a very powerful language, and I don't want a replacement.
3) The start up must be instantaneous. At least as fast as Emacsclient. If possible, as fast as VIM.
4) The system should not become slower for large projects. I worked in a medium size system, and Eclipse was much slower than Emacs.
5) Of course, something like Emacsclient is a must. I want to run Eclipse in a machine, and run a client in a small tablet.
6) Plugins should be easy to install. Something like VIM, or like Emacs. I was not able to install a single plugin for the languages I use. Eclipse would not find the plugins, and would not recognize the format of the plugins. This never happens in Emacs or VIM.
7) I want to see all my files, write my projects the way I want, using the technology I need. Eclipse should easily browse, organize, compile, and execute everything. Of course, there are people who work in different countries. Therefore, projects are often distributed in many machines, small and large, connected in a network (the Internet, for example). I want Eclipse to download, install libraries for me, combine different languages, and compile my programs. I have this in Emacs, I think it is not difficult to have the same thing in Eclipse.
Of course, a good emulator for Emacs MUST include Emacs Lisp. Of course, Common Lisp would be much better. By the way, it is not difficult to substitute Common Lisp for Emacs Lisp in Emacs. I hope that I can substitute Common Lisp for Javascript in Eclipse.