Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

My day job is java/web developer. I have been using eclipse for ~5years. I think its excellent and I also use Webstorm for javascript and html/jsp.

I do on occasion need to ssh into server and mess around with config files; for this I use vi and it pains me. I have to get up a webpage listing the syntax/commands : press escape, then asterix, turn around three times and the text will be entered two lines above your cursor. Its so unintuitive to me, and I imagine anyone who grew up in the late eighties nineties.

Here are the main reasons I think eclipse is brilliant(and I assume other IDE's), and do not switch to emacs and/or vim.

  • Error highlighting with no need to recompile project.
  • Code assist.
  • Refactoring.
  • Opening call hiearchy/Opening declaration.
  • Fully integrated with source control.
  • Debugger is included.
  • availablity of 3rd party plugins - eg findbugs/checkstyle.

One of the arguments I hear is that with emacs/vim you can create your own plugins - well OK, but you can do that in eclipse too. But you don't need to as everything is already there! Its like saying buy this half built car, you can build the rest yourself.

Why are people using emacs/vim ? Do people who use it actually work on complex object-oriented projects in large organisations ?

What are the reasons to switch to vim/emacs. How would my productivity increase if I did switch?

share|improve this question
1  
Can you please rephrase the title? It doesn't make any sense. –  Vetle Nov 18 '10 at 9:56
4  
I usually use nano, rather than vim, simply because I don't use a CLI often enough to have learnt all of the vim commands. If you only use it occasionally, I would think something simple like nano would serve you better... –  Dean Harding Nov 18 '10 at 12:08
show 6 more comments

closed as not constructive by Mark Trapp Feb 23 '12 at 16:36

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.If this question can be reworded to fit the rules in the help center, please edit the question.

16 Answers

up vote 28 down vote accepted

Use whatever tool fits your needs. Knowing VIM or Emacs is a good thing if you ever have to login into a remote server and edit a config file or something similar. I know VIM reasonably well, but I wouldn't use it to develop in Java. That's what Eclipse, Netbeans etc. are made for.

share|improve this answer
4  
@NimChimpsky I use emacs for some languages like C, ruby, python, haskell. But for Java or C#, I believe is better to use an IDE. In my job I use C# with VS. Just use the tool that you feel is more productive. –  hiena Nov 18 '10 at 11:50
6  
It's funny that if you ask someone "Why learn vi" the answer ALWAYS is "someday maybe you have to login to a remote server and edit some config file". I wonder how many developers actually had to do this. –  Oliver Weiler Nov 18 '10 at 23:08
2  
P.S.: I personally love vi but not because I think it's the best editor in the world but because it makes me feel superior :-). –  Oliver Weiler Nov 18 '10 at 23:08
2  
@Helper Method: I surely have to do this every now and then! Unless you are strictly working in an MS environment, it's bound to happen. –  user281377 Nov 19 '10 at 9:05
show 6 more comments

Emacs and Vi still have a place.

  • They are ubiquitously available in Unix and Unix-like environments, and can be installed on most other popular platforms.

  • They are popular and stable, so learning them once pays off over the long run.

  • They run over a text terminal, so you can use them in telnet and ssh sessions.

  • They provide editing modes and syntax highlighting for a wide variety of languages, including very new and very rare languages. (This is one of my favorite advantages.)

The key to understanding these programs, though, is to know what problems they were originally meant to solve. For Vi this was editing text files over terminal connections as slow as 300 Baud. In that environment you don't want to display menus or radically change the screen contents if you can avoid it.

Emacs was intended to be used in a faster environment. It's strength was that it could be loaded once and never exited. The user could accomplish any other task they needed from Emacs without leaving, and often in a more friendly way than if they had to do it from the command line. People didn't have a graphical desktop environment with an Emacs window open. Emacs let the user accomplish almost any normal task (and many strange ones) with just a few key strokes. Anything not built in could be scripted.

Obviously peoples' needs have changed a lot since these programs were introduced, but they still have some real strengths. I've learned the basics of both, and use them on a weekly basis. Still, I think their strengths are often overstated. They have achieved such legendary status that people don't admit to their weaknesses and instead tend to think they are doing something wrong if Emacs/Vi doesn't make them more productive than Eclipse or Visual Studio.

Now to the point.

Java is a popular language with excellent support in Eclipse, and odds are you are developing code on a modern operating system that lets you quickly accomplish common tasks and script others without doing it through your IDE. I don't think it would make sense for you to switch.

share|improve this answer
4  
+1 for good explanation of strong points and purpose of emacs and vi –  Larry Coleman Nov 18 '10 at 15:13
show 2 more comments

I have been using emacs for 5+ years. I can no longer tell you the key combinations I'm using, my fingers just remembers them and have to look at the keyboard just to see what my hands are typing.

A few years ago I started using Eclipse, and there is no chance I'm going back to emacs freely. Sorry muscle memory, even though you are missing ye old C-x r SPC 1, Eclipse makes me a lot more productive and that is what counts.

No, I don't think you should switch, but you should dedicate a couple of hours to learn the basics of vim so you don't have to look it up anymore.

share|improve this answer
show 2 more comments

Why should I switch to vim or emacs?

Most likely, you shouldn't switch. Vim is an excellent, powerful text-editor, but it isn't a substitute for an IDE, and shouldn't be! Eclipse is very good at its subset of IDE-specific things, and vim is very good at its subset of text-editing-specific things. Each has its own, different, focus.

I know there are plugins that extends vim's functionality so that it can do many of the same IDE-specific things an IDE can. But it still isn't vim's main strength, and an IDE will almost always be able to do it better. Because that is what they are focused on.

What I do in my daily work is use both Visual Studio and vim for editing C#. It works very well for me, and I would never cut out one of them to rely exclusively on the other.

As far as emacs goes, I am no expert, but I don't think it can compete with Eclipse's IDE features when it comes to Java (please correct me if I'm wrong). If you're developing in lisp, then it certainly can be considered an excellent IDE, but I don't think it has the same support for Java.

So if you want a more powerful text editor to use alongside Eclipse, then I would definitely recommend you learn either vim or emacs. But as a supplement, not as a replacement. It can really pay off in the long run, even though neither of them have a particularly easy learning curve : )

Here is a nice longish read about the strengths of vim. And here's a list of some nice tricks you can do.

share|improve this answer
add comment

Basically, read this(PDF) to see why Emacs is powerful. Once you know Lisp, it is almost trivially easy to write extensions for it (I have several source control workflows and deployments scripted through an add-on I wrote for myself called employer-mode). As far as what you list above;

  • Error highlighting with no need to recompile project. Doesn't make sense for all languages. You can easily integrate REPLs of many languages into it. Right now, I have ruby, python, haskell, common lisp, scheme and erlang all hooked into emacs. Incidentally, the JavaScript addon js2-mode has full incremental "compilation" so it highlights things like syntax errors for you, so it's certainly possible, but not the norm
  • Code assist. there's an addon for that called autocomplete.el, I believe, check the Emacs wiki
  • Refactoring. I assume you mean "automated refactoring", which doesn't make sense in all languages. Probably exists for some, but I don't know.
  • Opening call hiearchy/Opening declaration.
  • Fully integrated with source control. It has a git-mode built in as of Emacs 22.3, not sure about other source control
  • Debugger is included. Language-by-language basis here. Generally, if it has REPL integration, it has an Emacs debugger too, but it's not universal
  • availablity of 3rd party plugins - eg findbugs/checkstyle. don't know about those specific ones, but there's plenty of addons for it, from the why-isn't-this-in-the-base-package-useful, to the utterly frivolous

That said, if you don't like Lisp, and you don't intend to learn it, I can't honestly recommend Emacs. The win you get out of it is learning about tool-crafting and applying those principles to increase your own productivity, not getting a bunch of off-the-shelf mods and stringing them together.

share|improve this answer
6  
"ruby, python, haskell, common lisp, scheme and erlang" - this list makes me think you are a student –  user281377 Nov 18 '10 at 12:17
1  
@ammoQ - Not a student; though I am young (26). My day job is hacking on PHP/Common Lisp at a small IT company. I use Emacs for this purpose (the list of languages there is just what I have run commands bound for, not necessarily stuff I use professionally, or even on a day-to-day basis). –  Inaimathi Nov 18 '10 at 14:26
show 3 more comments

Personally, I like Vim because it's extremely good at editing text, i.e. very ergonomic (the keybindings don't strain my hands so much and I don't need to use the mouse so much) and efficient to use once you get the hang of it (which will of course take time and patience, since it's not the most intuitive editor for beginners).

I would however prefer Eclipse for large-scale Java development due to the many features that are readily available. Of course, there are some plugins that can make Eclipse a bit more tolerable.

share|improve this answer
add comment

I see two options here:

  • Use Nano instead - This is exactly like Notepad in Windows for Linux. Requiring no hotkey combinations, you just type nano somefile.conf and you have a nice editor. You can even add syntax highlighting
  • Keep the program locally and sync over SCP to the server - I do this when I need to work on a small website but don't have enough resources to run apache locally. I simply bring up WinSCP, bring up the directories I want, and use "Keep remote files up to date". Changes are usually reflected in seconds
  • Use a plugin in your editor/IDE to work "directly" with the remote file - Before I cared about revision control, I simply fired up Notepad++ (my prefered editor) and used NppFTP to work on the files. NppFTP is faster than the WinSCP option since Npp tells it immediately when a file is saved, which gets immediately uploaded. However as I said you loose revision control. I'm sure there's a plugin for Eclipse you can use

Hope this helps

share|improve this answer
show 2 more comments

If you're happy with Eclipse, then don't switch.

If you can use Eclipse everywhere you need, don't switch.

If your project/company pretty much exclusively uses Eclipse, don't switch.

If you only rarely need something else, print out a cheat-sheet for one of the editors and pull it out of the drawer when you need it, and then go back to using Eclipse.

See the (same) question over at SO: http://stackoverflow.com/questions/1346820/what-are-the-efficiencies-afforded-by-emacs-or-vim-vs-eclipse

As far as answering, "Do people who use it actually work on complex object-oriented projects in large organisations?" - Hold onto your hat sonny, but the answer is "yes". I've worked on projects with tens of millions of lines of code used in the critical path of designing the very CPU running the computer you're using to ask this question. And people tried Eclipse but found it to be too slow and clunky (though, admittedly, we were not using Java).

share|improve this answer
add comment

The best tool (in the short term) is one you're highly proficient with.

People use 30+ year old technology because they're highly proficient with it. They built their workflow and habits around these tools. If you're more familiar with a modern IDE like Eclipse, there isn't much reason to switch. Learning how to use Eclipse more efficiently is a better investment of your time (e.g. use Mylyn).

share|improve this answer
add comment

I am currently trying to switch from NetBeans to vim. Learning vim takes time and practice, but I see its advantages over, let's call them, "GUI editors" for certain cases.

But, unlike you, I am coding mostly Ruby, and I don't need all that code-generating, auto-completion, refactor-my-code black magic that NetBeans and Eclipse offer. If I were coding Java or C# I would most certainly not try to switch at all.

share|improve this answer
show 1 more comment

As a long-time user of emacs, I find emacs quite comfortable as an editing and development environment (and to some extent, it also integrates with build process, version control, quick context-sensitive search and the like, so I guess that qualifies it as an "IDE").

I'm also realtively comfortable with using vi and vi-like editors (I started out using ed, because I thought emacs was too complex; in retrospect that is backwards, but it did give me a solid foundation for future learning of vi). I use vi primarily for "small quick edits", primarily on remote machines where emacs isn't installed.

For your "I do on occasion need to ssh into server and mess around with config files; for this I use vi" scenario, I'd recommend a small set of commands and some general thoughts around vi:

  • Vi isn't modal, it has "a" (append), "A" (append at end of line), "i" (insert) and "I" (insert at start of line) commands, taking the text to insert as an argument and signalling "end-of-command" with Esc
  • h, j, k and l are movement keys. It MAY work using the arrow keys, but as the typical VT-style "I am an arrow key" sequence starts with Esc, this will break the text-insertion command you're not thinking of
  • :linenum moves you to line linenum, line 1 is the top-most line and line $ is the bottom-most one
  • . is the "repeat last command" command (see the first bullet point)

It shouldn't take more than an hour or two of playing around with vi to be at the "I can confidently edit a text file, but I may not be efficient with it" and that's as good as you'll probably need to be. Failing that, any editor that doesn't faff about auto-converting between tabs and spaces should be "good enough" for your purposes. If Eclipse is installed on all your remote servers, I don't see using that as a big problem, really.

share|improve this answer
show 1 more comment

I have no problem with the various UNIX editors available, but I only ever use them under protest. Not, as I say, because I have an issue with them but because if I'm having to use them it means that our deployment process is in some way lacking.

This probably deserves a little more context: I work on large-scale e-commerce solutions, everything that governs the running of our systems is generated by a one-click build/deploy process. We have an array of test environments so at any given time I can make a change via Eclipse, check it into cvs and trigger a build/deploy to prove that my fix has worked. So- if I'm hacking around in 'vi' then it's because we can't wait for the 1-hour turnaround of a deployment or because the deployment doesn't cover the files I'm editing and needs to be extended to do so (otherwise I'll be hacking in vi the next time the file in question needs changing).

share|improve this answer
add comment

Both emacs and vim are very configurable and powerful editors, and both provide big productivity wins once the basic concepts are grasped.

Vi wins with what are essentially set-based operations. For example, changing all instances of "foo" to "bar" in a class definition is a one-liner.

Emacs is equally powerful, but you have to learn Emacs Lisp to use it to its full potential.

In either case, it's only worth switching if you plan to use emacs or vi for everything.

share|improve this answer
add comment

Personally both programs drive me up the wall. The problem with Eclipse is that its slow as snot when you're working on a large project and that's when its not doing 'DGLP Indexing' or whatever. want to refresh your repository? got 15 minutes? Oh and how about that nifty trick where you Ctrl-C some text then Ctrl-P it somewhere but instead of it going where you wanted it to it opens a completely different file and pasts over something else and you're left wondering wtf was there in the first place. Oh and did i mention working with eclipse on a large project over a vpn? practically impossible.

As for vim, its nice and fast assuming you know the multitude of completely senseless key combinations to make it do something and good luck if you find yourself in some unknown mode by accident. Also with vim you pretty much have to know your entire projects directory structure in your head in order to open the correct files. Vim's main advantage is that in theory you can create code faster because its all keys, but in reality i don't care how much text i'm writing, it not the volume of text that matters its the quality of the code and often quality code requires staring at dozens of files for hours on end until you figure out the exact right thing to type (which is usually very short).

What i wish is that someone would write a command line program, like vim, that actually has a directory structure like eclipse on the side or something that you could expand/collapse and open files from. Does anybody know anything like this?

share|improve this answer
3  
You can just open a directory in a buffer and it will list the files in the directory. Move the cursor over the file you want to edit, hit return, and it will open that file. A variety of vim plugins (like NerdTree) offer more sophisticated features like automatically splitting the window, opening the file in one pane, and keeping the directory tree in the other. The general difficulty with vim and emacs is not that they lack features, it's that the features are not readily discoverable by browsing menus, you have to read the help documentation. –  Charles E. Grant Sep 15 '11 at 1:13
show 1 more comment

If you aren't happy with VIM or EMACS, you could look on that machine for other text editors. There might be some flavor of nedit or gedit or somesuch that you can use which will have more familiar commands (ctrl x,c,v and s do what you'd expect for example).

You probably have more than two choices on your distro, it is worth it to take a look.

share|improve this answer
add comment

I am very much an Emacs guy. I use it for all my programming, and actively encourage my co-workers to use it, too (and they actively ignore me). I find it far more productive than any IDE, and I would never change.

Unless I am writing Java or C# (and I imagine there's other languages in this category). They have such large libraries of stuff with long names, that the gains I get from using Emacs are completely lost in trying to remember everything.

I certainly encourage you to try vim and/or Emacs. But you're likely going to end up back in Eclipse for Java.

share|improve this answer
add comment

Not the answer you're looking for? Browse other questions tagged or ask your own question.