Related
After reading books like The Pragmatic Programmer, one thing it strongly suggested was to pick a text editor and master it. I chose to use Emacs and stuck with it for about half a year. However, the one thing that kept pulling me back to a full-fledged IDE was debugging.
After attempting to use xdebug via command-line for a couple of weeks, it was no surprise that the debugging tools that Netbeans/Eclipse provide are far superior to CLI.
So fellas, are there any Linux tools that allow you to place breakpoints and help visualize your application at run-time, or is there a reason why I should stick to suffering through CLI debugging?
Any feedback appreciated!
I'm using Vim all day for coding. But when it comes to debugging, I always take the debugger of my IDE (Visual Studio) because while debugging, I take the mouse and hoover over some variables, edit their values and so on. That's not a task that I'd need a powerful editor for.
That's my advice to you: for coding and editing, take an editor; for debugging take a (graphical) debugger (DDD, Eclipse, whatever). It's not a sacrilege to switch tools, only to take the wrong tools for the task to be done.
Like this: http://www.gnu.org/software/libtool/manual/emacs/GDB-Graphical-Interface.html#GDB-Graphical-Interface ?
Tutorial : http://www.youtube.com/watch?v=vHOzMOzzxDA
Same. I use IDEs for the heavy stuff and Emacs for quick stuff.
The reason to be proficient with a light-weight editor is to be nimble when you know what you want to do. Open this file, find-tag, edit, magit-status, commit, push. Bam. You don't want startup-time & instability to be cock-blocking your effort when you've got at goal. Vim is installed on most servers, and if you're editing on production, you'd better have a goal.
IDEs on the other hand (Aptana for me, PHP) I find are useful for "studying". Debugging, stepping through code, analyzing code, searching (Eclipse's tree-results search over Emac's rgrep ANY day when there are multiple results).
I consider myself quite proficient with using Emacs as a full-fledged IDE via ECB, geben, rgrep, ctags, magit, etc. I used it as such exclusively for over a year -- but in all honesty, it hindered my productivity -- the heavy tasks take too many steps. Now I use Aptana & Emacs really about 50/50 throughout the day.
Light editors for light stuff, Heavy editors for the heavy stuff
there are definitely debugging solutions in vim see http://jaredforsyth.com/projects/vim-debug/, there are more but I haven't tried them, I tend to switch back and forth from an ide to vim.
What practical, objective differences are there between Emacs and Vim? For example, what can be done using one but not the other (or done more easily with one than the other)? What should I know in order to choose one to learn?
(the text below is my opinion, it should not be taken as fact or an insult)
With Emacs you are expected to have it open 24/7 and live inside the program, almost everything you do can be done from there. You write your own extensions, use it for note-taking, organization, games, programming, shell access, file access, listening to music, web browsing. It takes weeks and weeks till you will be happy with it and then you will learn new stuff all the time. You will be annoyed when you don't have access to it and constantly change your config. You won't be able to use other peoples emacs versions easily and it won't just be installed. It uses Lisp, which is great. You can make it into anything you want it to be. (anything, at all)
With Vim, it's almost always pre-installed. It's fast. You open up a file do a quick edit and then quit. You can work with the basic setup if you are on someone else's machine. It's not quite so editable, but it's still far better than most text editors. It recognizes that most of the time you are reading/editing not typing and makes that portion faster. You don't suffer from emacs pinkie. It's not so infuriating. It's easier to learn.
Even though I use Emacs all day every day (and love it) unless you intend to spend a lot of time in the program you choose I would pick vim
Vim is not a shell. And it does not communicate well with subprocesses. This is nearly by design, whereas in Emacs, these elements are included by design. This means that some stuff, like embedding a debugger or an interpreter (yielding a sort of IDE), is difficult in Vim.
Also, Emacs shortcuts are mainly accessed through modifiers, and obviously the Vim interface is famously modal, giving access to an absurd amount of direct keys for manipulation.
Emacs used to be the only editor of the two that was programmable, and while Vim has a lot of weird levels to its programmability, with the addition of Python and Ruby bindings (and more, I forget), Vim is also programmable in most ways you'd care for.
I use Vim, and I'm fairly happy with it.
Vim:
better as a simple editor (fewer keys required for simple tasks)
more active scripting community - internal language: vimscript
one central repository of scripts, plugins, color schemes, ...
also extensible in python, ruby
can be made portable (emacs has some problems with that)
Emacs:
non modal by default (most of today's editors have taken this approach). Though there is evil-mode which emulates vim behavior.
more powerful language for extending it (elisp is a full blown language, and in emacs you can practically redefine everything; while in vim you cannot redefine build in functions of the editor. On the downside, vimscript is relatively similar to today's dynamic languages while elisp doesn't resemble pretty much anything)
more extendible
excellent support for GNU tools (the bunch of them)
Personally, I prefer vim - it is small, does what it's supposed to do, and when I wish a full blown IDE I open VS. Emacs's approach of being an editor which wants to be an IDE (or should I say, an OS), but is not quite, is IMHO, outdated. In the old days having a email client, ftp client, tetris, ... whatnot in one package (emacs) made some sense ... nowadays, it doesn't anymore.
Both are however a topic of religious discussions among the programmer and superuser community users, and in that respect, both are excellent for starting flame wars if put in contact (in the same sentence / question).
If you are looking for an objective analysis of both the editors, look at their origins and the philosophy behind their respective designs. Think, which one would suit you better and learn it (and learn it and learn it, because it takes time before you being to discover its true utility as against any IDE).
An Introduction to Display Editing with Vi was written by Bill Joy and Mark Horton and he explains why he choose modal design and rationale for various key strokes ( it helps me to remember that CTRL-W +W (will switch to next Window and it will same for CTRL W+ CTRL W, just in case you held the CTRL key for a longer duration.
Here is a link to Emacs timeline and has the reference to Multics Emacs paper. Hereis RMS paper on Emacs, where I see the stress is on a programmable text editor (even way back in 1981 and before).
I have not read the emacs papers, but have read Bill Joy's vi paper a couple of times.
Both are old, but still you will get the philosophy and you might choose to use the current tool (vim 7.x or emacs 25?)
Edit: I forgot to mention that it takes patience and imagination to read both these papers as it takes you back in time while reading it. But it is worth.
Vim was always faster to start up than Emacs. I'm saying that on any machine, out-of-the-box installs of Vim will start up faster than out-of-the-box installs of Emacs. And I tend to think that after a moderate amount of customisation of either one, Vim will still start up faster than Emacs.
After that, the other practical difference was Emacs' modes. They make your life tremendously easier when editing XML, C/C++/Java/whatever, LaTeX, and most popular languages you can think of. They make you want to keep the editor open for long sessions and work.
All in all, I'll say that Vim pulls you to it for short, fast editing tasks; while Emacs encourages you to dive in for long sessions.
VI is always available and will run on the most crippled, single user mode, broken graphics, no keymap, slow link machine - so it's worth knowing how to edit simple files in it just for sysadmin tasks.
Emacs is a complete user interface in an editor. The idea is that you fire up Emacs when you start the machine and never leave it. It's possible to have thousands of sessions present.
Whether learning the capabilities of Emacs are worth it compared to using a GUI editor/IDE and using something like python/awk/etc for extra tasks is up to you.
I'm a full-blown Emacs fan-boy, but I knew VI long before I knew Emacs. That said, I make all of my people learn VI because it's always available, everywhere. Can't go wrong with either one of them.
Seems an answer has been selected already, but the big difference to me has always been the modal vs. non-modal. Vim is modal, which means that it makes optimizations based on a specific set of usage modes. At least that's how I've always looked at it. This makes using Vim a different experience because instead of having a work area that you type code in, you really are telling an environment to act on the text. This is why people say things like with Vim you really are learning a language. The :wq and :s/foo/bar is all part of a shell like environment that edits and reads text.
Emacs on the other hand is much closer to most editors/word processors/etc. you see today. You have a workspace that has a highly programmable interface. That is why you see things like email, irc, shells, etc. As a programmer it is easy to think in terms of saying "take the line number I'm on and do something with the information". The desire to leave the editor becomes less because instead of having to quit, open some other app/language and do things on some text, you have Emacs where you can do these things within the scope of your editor.
The two ideas are not necessarily contrasting, but it is simply that they reveal two different focuses. Personally I use Emacs, but I've seen folks who know Vim really well and can honestly say it doesn't matter which you choose. I tried Vim first but Emacs ended up sticking for me. It is true that no matter what you choose, you should be at least somewhat proficient in Vim as it really is always available.
There is a huge difference on a day-to-day level - Vim (or any vi variant) is inherently modal (you go into command modes where you cannot edit) and Emacs (along with most other editors) are not.
Sure, using menus and such you don't have to actually enter command mode in Vim - at first. But to use even a tiny fraction of the power of Vim you will. That is at the heart of the Vim/Emacs debate.
Personally, I also think Emacs is far more extensible. You can find Elisp packages for many things.
I am curious, though, why you are thinking to learn one of these over a more traditional IDE. What is it you want to learn one of these for?
I started with vi, went to emacs, then to vim. I've been thinking of trying out Emacs to see what's changed in the last five years. (Speaking of IDE's, I had gotten into eclipse for a while, but I prefer my terminal window connecting my mac to my (husband's) linux box).
The cut and paste thing has been bothering me lately. Cut and paste in Vim takes more steps than in Emacs, IIRC. And pasting from say a browser to a terminal window is irritating unless you do something fancy that I don't feel like doing, so I put up with the weird indentation. I think, editing multiple files in emacs was easier. At least jumping from one file to the next if you have them both up on the screen.
I haven't played with the fancy features of either vi or emacs, as I just like to get to the business of coding. All I need is the pretty colors and proper tab to space conversion (especially important with python).
I think it all depends on if you want to use :wq or Ctrl-x Ctrl-s (IIRC) to save a file if you don't care about the fancy stuff.
#mgb was correct. I've been in the bare minimum linux to fix something just a month or two ago in a Debian distro. vi was the only editor available.
There is a lot of thing that have been said about both editors, but I just have my 5 pence to add. Both editors are wonderful and you cannot go wrong with either of them.
I am a vi/vim user for about 15 years now. I've tried converting to emacs several times but every time was rather discovering that vim actually can do the missing thing out of the box without the need to write a lisp extension or install something.
For me the main difference in the editors that vim makes you use the environment/OS, while emacs tries to encapsulate it or replace it.
For instance you can add a date in you text by :r!date in vim, or calendar with :r!cal 1 2014, or even replace the contents of you buffer with the hex version of the contents. Eg. :%!xxd, edit hex and then get back with :%!xxd -r, and many more other uses, like builtin grep, sed, etc.
Another example is use with jq and gron. Eg. paste json blob to the editor and then run for tranformation:
:r!curl -s http://interesting/api/v1/get/stuff
:%!gron | grep 'interesting' | gron -u
OR
:%!jq .path.to.stuff
Each of the piped commands above can be run separately via :%!<command>, where % means all document, but can also be run on selection, selected lines, etc. Here gron output can be used as jq path.
You also get the EX batch editing functionality, eg. Replacing certain words, reformatting the code, converting dos->unix newline characters, run a macro on say 100 files at a time. It is easily done with ex. I am not sure if emacs has something similar.
In other words IMHO vim goes closer to the unix philosophy. It generally simpler and smaller, but if you know your OS and your tools, you wont likely need more than it(VIM) has to offer. I never do.
Besides vi is defacto standard on any unix/linux system, why learn to use 2 tools that do the same thing. Of course some systems offer mg or something similar, but definitely not all of them. Unix + Vi <3.
Well, just my 5 pence.
I would like to put here a quote from the book "The Art of UNIX Programming":
Many people who regularly use both vi and Emacs tend to use them for
different things, and find it valuable to know both.
In general, vi is best for small jobs – quick replies to mail, simple
tweaks to system configuration, and the like. It is especially useful
when you’re using a new system (or a remote one over a network) and
don’t have your Emacs customization files handy.
Emacs comes into its own for extended editing sessions in which you
have to handle complex tasks, modify multiple files, and use results
from other programs during the session. For programmers using X on
their console (which is typical on modern Unixes), it’s normal to
start up Emacs shortly after login time in a large window and leave it
running forever, possibly visiting dozens of files and even running
programs in multiple Emacs subwindows.
What I really want to highlight here is the: «Many people find it valuable to know both.»
For me pros of emacs are,
tramp-mode allows you to edit remote files over ssh. just like local files.
tramp-mode + dired = full featured sftp client
support for every language you will ever need.
built in terminal emulator(term-mode) so i can keep coding without switching between applications.
extensibility anything you don't like you can change using lisp.
For me, emacs has better development tools(not only tags based tools).
Cedet(c/c++)
Xrefactory(c/c++/java)
Slime(common lisp)
JDEE(java)
ECB(code browser)
GDB Support
NXML(xml)
Benefits of Emacs
Emacs has both non-modal interface (by default) and modal one (e.g. it can emulate vim and vi through Evil, Viper, or Vimpulse).
One of the most ported computer programs. It runs in text mode and under graphical user interfaces on a wide variety of operating systems, including most Unix-like systems (Linux, the various BSDs, Solaris, AIX, IRIX, macOSetc.), MS-DOS, Microsoft Windows, AmigaOS, and OpenVMS. Unix systems, both free and proprietary, frequently provide Emacs bundled with the operating system.
Emacs server architecture allows multiple clients to attach to the same Emacs instance and share the buffer list, kill ring, undo history and other state.
Pervasive online help system with keybindings, functions and commands documented on the fly.
Extensible and customizable Lisp programming language variant (Emacs Lisp), with features that include:
A powerful and extensible file manager (dired), integrated debugger, and a large set of development and other tools.
Having every command be an Emacs Lisp function enables commands to DWIM (Do What I Mean) by programmatically responding to past actions and document state. For example, a switch-or-split-window command could switch to another window if one exists, or create one if needed. This cuts down on the number of keystrokes and commands a user must remember.
"An OS inside an OS". Emacs Lisp enables Emacs to be programmed far beyond editing features. Even a base install contains several dozen applications, including two web browsers, news readers, several mail agents, four IRC clients, a version of ELIZA, and a variety of games. All of these applications are available anywhere Emacs runs, with the same user interface and functionality. Starting with version 24, Emacs includes a package manager, making it easy to install additional applications including alternate web browsers, EMMS (Emacs Multimedia System), and more. Also available are numerous packages for programming, including some targeted at specific language/library combinations or coding styles.
Benefits of vi-like editors
Edit commands are composable
Vi has a modal interface (which Emacs can emulate)
Historically, vi loads faster than Emacs.
While deeply associated with UNIX tradition, it runs on all systems that can implement the standard C library, including UNIX, Linux, AmigaOS, DOS, Windows, Mac, BeOS, OpenVMS, IRIX, AIX, HP-UX, BSD and POSIX-compliant systems.
Extensible and customizable through Vim script or APIs for interpreted languages such as Python, Ruby, Perl, and Lua
Ubiquitous. Essentially all Unix and Unix-like systems come with vi (or a variant) built-in. Vi (and ex, but not vim) is specified in the POSIX standard.
System rescue environments, embedded systems (notably those with busybox) and other constrained environments often include vi, but not emacs.
Source: https://en.wikipedia.org/wiki/Editor_war
The biggest difference for me in choosing to use emacs over vim was the built in gdb support in emacs. Vim doesn't have this included in it's default distribution and the project there for integrating gdb and vim was nearly impossible to get working with MacVim
Now you do not even need to think about the difference between these two because of Spacemacs. It is a community-driven Emacs distribution.
As it said,
The best editor is neither Emacs nor vim, It's Emacs and Vim.
Spacemacs combines the best from both Emacs and Vim, which make your life and job much easier.
See screenshot below,
(source: spacemacs.org)
Its like apples and oranges. Both have different design and philosphy. Vim is a Text Editor while Emacs is a Lisp Interpreter that does Text Editing.
I use Vim because its fast, sleak, and really good at manipulating texts. It has a composable natural key binding that can make your development tasks really harmonic. Vim is based on the simple *nix philiosphy of doing one thing really well - i.e Text Manipulation.
Extending Vim using bash/zsh and tmux is usually easy and allows you learn a lot of things. IMHO this is a good learning curve. The key thing is to learn how to integrate these things to get a larger working application. With Vim you'll need to learn integration because it doesn't naturally integrate unless you tell it how to. Another worthwhile extension which I use is Tig . Its an ncurses based Git frontend . I just have a binding that opens Tig silently and then I do all the Git stuff there.
Its up to the end user to decide what works best. That Emacs and Vim has stood the test of time is proof of their worthiness. Eventually a good programmer needs nothing more than a pen and a paper to be creative. Good algorithms don't need editors to back them. So try them both and see what makes you more productive. And learn design patterns from both these softwares as there are plenty to learn and discover!
Emacs has viper-mode, so in some real sense, it provides a superset of features (excepting those described in What Vim features are missing in Emacs with Viper and Vimpulse?).
vi (and VIM IIRC) is lighter weight (it can edit files in place), but offers fewer features (subprocess communication, extension language).
Emacs is really more of a do everything program, and vi(m) is really just an editor. If you are editing text, they are both fine, but I prefer emacs, simply because I have to shift one off the home row to move around, and keep typing the wrong things in command mode. I you don't have that problem, vi(m) may be the editor for you.
A jaundiced point of view:
vi (not vim) is a professional necessity. You always have some form of
vi easily available, no matter what the environment. You can be in vi
when in emacs, you can be in vi to build bash commands in unix-land.
Even Microsquish has to support vi (although they do a good job of
hiding it) because of gov't and corporate compliance with published
standards.
In my opinion, if you are in a hands-on job in a busy environment--not
a hothouse flower confined to one fancy rig in a development
environment, or in academia--knowing a lot about a fancy editor is a job
handicap. Don't learn all the fancy tricks in vim or emacs, and don't
develop a bunch of macros to make the editing environment bend to your will.
It's an enormous time sink that gets in your way when you attend to
different machines that you probably can't justify in a factory
environment.
Read Bill Joy's paper--it is a very competent, perhaps even
beautiful, engineering exercise in editing plain text very, very
fast. Parito's rule applies here: 80% of the fruit is in 20%
of the baskets. Editing plain text very very fast is the crux of
editing competence--all else is optional--and sometimes hurtful.
In your question, you haven't mentioned that you want it to program in Lisp! But as you have been commenting your answers, I have understood that you actually want a LISP programming interface.
For that precise task, simply forget about Vi. Emacs integration with LISP is wonderful! You should use SLIME. You will then have wonderful integration with the REPL, being able to eval functions, buffers or files directly into a running interpreter in an emacs buffer and much more...
I was user of vim first, then I switched to emacs, then to vim, now I'm experimenting with emacs again.
Both are great editors.
Both are very extensible today
Both have great plugins and community
As developers we type a lot, and, at last for me, moving around in buffers and files are the biggest repetitive tasks, so I want a editor where I CAN MOVE FAST!
The motivation for experimenting with emacs again is that I fell it Ctrl leaded keybinds faster than vim, and easier to reason about.
In vim you have modes, you have insertion mode, visual mode, normal mode, what happens when you press something depends on the mode that you are, is a stateful aproach to editing. You move, enter in insert mode, edit, get out of insert mode and move again. I frequently lose my self if I miss a ESC press or something like this.
In emacs there is no mode, basically you press Ctrl with your pink and type the keystroke, like C-x C-f, C-x C-s, C-x C-c. There are keybinds where you need to release ctrl key, I hate this ones and always replace them by ones with control pressed.
I think that emacs approach is faster to think and type, but vim has another strength, to. Its commands are composable, they usually has a format . For example, to delete a line you can use dd, to delete a word dw. Plugins make use of that felling, with vim-surround plugin you can delete quotes with ds" (delete surround "), delete up to next / dt/. Delete up to previous /: dT/ and so on. So as long as you learn the moving things start to get very interesting.
Summing up, today I fell that emacs keybinds are faster for macro editing and vim commands are more powerfull for microediting
I've been using vim for the last five years so I edit thinking mainly about words, lines, surrounding, blocks, etc. Delete this line, remove quotes, replace quotes,
delete word in cursor, I'm trying to findout the emacs moves for that
As a final quote I would say that, I care more about fzf than about emacs or vim, I would love to have a editor that is completely fzf based
If you move around a lot from site to site or your job involves loging on to production systems then vim is the way to go.
All *nix machines will have vi installed by default.
Most sysdamins prefer ksh as the default shell. ksh uses vi (or emacs) command keystrokes to search history and edit the command line.
If you dont know vi well you are severely handicapped when you log into a unix box with a standard configuraton.
For this reason alone I would recommend vim as your normal every day editor. I have seen emacs fans tear there hair out trying to amend config files on a bare bones unix server.
vim is a handy editor, you simple type vim filename to open the file, edit, save and close.
emacs is an "operating system" pretend to be an editor, you can eval code to change its behavior, and extend it as you like. A mode to receive/send email on emacs is like an email software on operating system.
When doing simple editing, for example, modify a config file, I use vim.
Otherwise, I never leave emacs.
I am an Emacs fan but encourage other developers to learn VI because:
you can use VI to edit the emacs makefiles.
VI includes ed commands and every UNIX user should know ed and sed.
I've noticed several comments about VIM starting faster than emacs. If you really care about that, run emacs in server mode and alias 'emacs' to 'emacsclient'. The client is super fast since all it does is tap the server on the shoulder and tell it which file you want to edit. On MacOSX, emacsclient is only 33K while emacs is 287M.
I'm not sure any of this is necessary on modern hardware. On my MacBook Pro (2013 Retina), emacs loads almost instantaneously when I run it from the shell. I detect no pause at all. When I run Emacs.app (the GUI version) it might take all of 3 seconds.
Most complaints I hear about emacs seem to come from people misinformed about emacs. Having used both vi and emacs since 1982, I definitely remember a time when emacs loaded much slower than vi and used most of the physical memory in my early UNIX boxes, but that is no longer the case and has not been for at least 15-20 years.
One complaint I will concede is "emacs pinkie". This never bothered me at all when I was younger. Now that I'm 58, my pinkie does get a bit sore from repeatedly accessing the Control key for emacs chording. This is especially true on the MacBook Pro keyboard where Control is moved one position to the right to make room for the "fn" key. It's not nearly as annoying when Control is the bottom left key.
I have worked with spacemacs for about 2 years and neovim for about a year now in a production/research environment. Spacemacs is emacs with couple of nice extra features like layers etc. And neovim is a fork of vim again with some extra features.
I am quite unsatisfied with both of them in terms of experience. And I am still on the look out for a long term solution for my text editing needs.
Here is a simple comparison:
Neovim, vim, emacs, spacemacs, etc all of those editors consume less ressources compared to most of the editors out there.
Neovim/vim is slightly faster than emacs, noticably faster than spacemacs.
In terms of editing experience. I can easily say that emacs packages feel superior. I think that's because they blend in better with the core of emacs.
Vimscript is nice and there are certainly great projects in the vim ecosystem as well. The good thing is they are better documented than most emacs projects I have seen so far.
Both can be glitchy depending on the package you are using. Spacemacs tend to freeze, and neovim tend to display scary error messages, so pick your poison there.
Modal editing in vim, is not an intuitive concept, but once you get used to it, you want it anywere. Both of the editor provide that.
Keystroke execution:::
vi editing retains each permutation of typed keys. This creates a path in the decision tree which unambiguously identifies any command , whereas Emacs commands are a combination of typed keys executed immediately, which leaves the user with the choice of whether or not to use a command.
Memory usage and customizability:::
vi is a smaller and faster program, with a more limited capacity for customization, whereas, Emacs takes longer to start up and requires more memory. However, it is highly customizable and includes a large number of features, as it is essentially an execution environment for a Lisp program designed for text-editing.
I think the main difference is the design target.
VIM is for UNIX as a working editor.
Emacs is for GNU and lisp hackers, so it has some mixed design element.
I use vim on my workstation, while I love emacs too.
Firstly Vi (original realization) not used today. That you say is some Vim derivation.
To extend Vim functionality you must recompile Vim, Emacs not.
Emacs has Vim in self (viper-mode).
Emacs usually need manually installation, Vim typically preinstalled on all Unix like OS (but if you have ssh access to host tramp-mode win Vim :).
If you try Vim you hate Emacs, so start from Emacs first.
Also read http://www.dina.dk/~abraham/religion/vi-tutorial.html (link go down so use this)
Anwer search in hxxp://en.wikipedia.org/wiki/Editor_war
I recently started picking up vi, going through some tutorials and trying to get used to it. But I still have some questions about it.
It seems to be nice for small one file changes, but as soon as I start to try doing bigger things it seems to be lacking. For example I'm used to have code formatting, import organizing, simple overview over all packages and other things that an IDE gives me. I saw some tutorials on how to use vi as an IDE, but it felt awkward at best.
Now I'm just wondering, what are the typical use cases for vi? Is it typically used to edit small files, or can it be used for larger projects? And if you use it in larger projects, how do you make it work? Or would it be a lot easier to use an IDE with vi keybindings?
People use non-IDE editors like Vi(m) for coding due to the following reasons,
They are non-distractive, allows you to concentrate on the job.
They do not clutter you screen area, offers you more code space
They are faster
They have better/faster/cooler text manipulation at the stroke of the finger
You happen to move your hands out of the keyboard less to hold the mouse, drag it here and there and click.
They also have the flexibility to support other tools like debugger, document viewer, etc.
They also have ways to get things like code folding, etc.
For a normal programmer whose ideal work cycle is sit, write code, test, debug, more code, test debug.. Vi offers a simplistic yet powerful environment to get the work done faster and more efficiently.
For someone who had years of using some IDE, it might be like using some prehistoric tool, but once they have been through the initial days, then there is no looking back. They'd feel like there is no better thing.
Why, oh WHY, do those #?#! nutheads use vi?
I've haven't done anything that you'd call a big project in python (only little test scripts), but I use Vim exclusively for writing large embedded C applications and I have never really felt the need for an IDE.
Vim is fast to start up, extremely fast to use and (with a bit of customisation) can do most things that an IDE can do. It'll do code completion, code auto-indentation and reformatting and it is very good at refactoring. The project plugin http://www.vim.org/scripts/script.php?script_id=69 makes it very easy to manage projects with lots of files and the taglist plugin http://www.vim.org/scripts/script.php?script_id=273 is great for browsing source code. It also allows you to have the C code open side-by-side with python code, assembly code and latex documentation without having to use a different tool for each.
Overall though, I think there is one really valuable thing that Vim gives you that very few other editors do and I would find it very hard to lose that: I can have a window split into three parts like this:
Each of the subwindows can either show a separate file or (as in the screenshot) a separate part of the file. I imagine emacs can do this (although I could be wrong), but I doubt many IDEs can. This can be invaluable for refactoring and for referring to other parts of the file.
I've used VI(M) and Emacs as my primary editors for years... I've tried switching to IDEs but find they can't get out of my way enough. I always end up back in VI(M) or Emacs after a while. One major reason is that I find my hands need to leave the keyboard too much in IDEs as they require the mouse too often... And I'm too lazy to setup my own shortcuts for everything.
Here's why I use it.
it's fast to start up
it's available across multiple platforms and is on all Unix machines
it's fast to use (keystrokes for common operations, operations based around words/paragraphs etc.)
However, I use IDEs for large scale development work, since I can't believe they can be beaten for productivity, given their code-awareness and refactoring capability. I use Eclipse, but I plug a VI editor emulator into it. See this answer for more details.
I saw some tutorials on how to use VI as an IDE, but it felt awkward at best.
There's one thing to do at the very beginning: throw your sense of aesthetics overboard. You will never get the same kind of graphical experience in VIM as you do in a decent IDE.
That said, VIM actually does offer many of the features of a full-blown IDE and has a lot of advantages besides. I use VIM for almost all of my developing work and all of my text documents (using Vim-LaTeX) – even though I've actually paid money for Apple’s office suite, iWorks.
There's one point that's still nagging me, though: I can't get IntelliSense to work. For me, that's a huge problem, especially when using languages such as VB, C# or Java, for which excellent IDE support exists.
So, the learning curve for VIM is steep but once you've passed a certain point it's everything but awkward. In fact, compared to VIM's editing experience, you will find that it's the IDEs that suddenly feel awkward because while they're good at bookkeeping stuff, they suck at editing.
I frequently work on a remote system, programming for a cluster, or editing config files on a headless box. All of these could be done with a file transfer, a regular IDE, and another file transfer, but it is so much faster to just use VIM through SSH.
You can find it (or easily install it) almost anywhere - Runs on all systems that can implement the standard C library, including UNIX, Linux, DOS, Windows, Mac, BeOS, and POSIX-compliant systems.
The ability to log into a remote server and confidently edit a config file is priceless.
Vim is not very good at code awareness. What it is good at is text manipulation. It provides you with the tools for you to edit text, not to edit for you. If you just do "small" edits and don't read up on the occasional "vim commands you wish you knew" you'll never understand the power provided.
code formatting
Formatting is done with =. You can also point equalprg to an external program to do the formatting for you.
import organizing
Vim won't be able to remove unused imports but if you select the import lines
:'<,'>sort
simple overview over all packages
:vs .
This will open a vertical window containing the current working directory :)
In conclusion, vim can't replace your IDE but it will let you edit your text.
As usuall: Choose your tool depending on the work you have to do! ;-) I'm using Vim and Visual Studio. You don't have to choose only one.
If you need an IDE, use an IDE. Vim is made for text manipulation.
It supports any languages. Try to edit a Ruby script with Visual Studio.
Performance on large files is much better than for most IDEs. Try to analyze a logfile having 100k lines and more using your IDE.
It runs on many plattforms and you can use it via a remote console, if you have to edit files on a server.
...
IDEs are specialized tools, which are good for problems they are made for. Vim is an incredible flexible and powerfull generall purpose tool.
This is obviously a hot topic so I'm going to give a list of reasons why I prefer IDE editor for coding.
1) I prefer to be able to fold sections of my code (I don't know whether Vi(m) can) without having to remember the command to do so or type it.
2) I prefer one click compile button/command as opposed to having to remember my compile command and it's library of options
3) I prefer the easier highlight copy paste operations without having to........ aah sod it!!
Well by now you get the picture. I'm not knocking Vi(m) I just think having your the elements and functionality of your coding environment visually represented makes for a clearer head and encourages exploration of options you may not know exists.
I much prefer vim over vi and prefer not to lump them together. Vim provides some features that are really handy and not always immediately obvious. Already mentioned was screen splitting. Also you may want to checkout ctags or exctags. These allow you to jump around the code base from within vim. I can place the cursor over a called method, jump to the definition, jump to a definition within that method, etc. Very powerful for tracing down bugs. Cscope is another similar program.
Vim will also allow you to run arbitrary shell commands within the environment and has powerful search and replacement features.
So an IDE will provide most of those, what will vim provide over a traditional GUI based IDE? That's easy, it runs on the CLI.
This allows me to login to my dev box, run screen (definitely something to checkout for the unfamiliar: http://www.gnu.org/software/screen/) and run multiple vim sessions within my screen session on my dev box. Now when I leave work for the day, I can leave my work session just as I left it, even while running builds. When I come into work the next day I can connect from my environment as if I never left.
Another reason to like vim or vi in particular, is that it can be found on virtually any Unix environment.
I am a quite happy user of Eclipse (I mostly develop in PHP and Python), however I found the answers to "What specific productivity gains does Vim/Emacs provide over GUI text editors?" interesting enough to make me wish to try out Vim or Emacs as well and see if they would turn out to be a better solution for me.
I have the general feeling that Vim and Emacs are not the kind of editor you learn by "playing with it" though. I have the impression you must dedicate some time and effort to "study" them a bit, before you can benefit from their power.
So, I have two questions for the community:
In the linked thread responders have essentially answered by commenting on Vim (often mentioning: "I'm sure Emacs has the same"). Google trends seems to indicate Vim is the mostly adopted between the two, however my first question is: knowing that I have no prior experience whatsoever on any of the two, and that I use and develop (mostly PHP and Python) on GNU/Linux systems (Ubuntu, Arch Linux), is there any of the two which would represent a better option to start with? (To be clear: my question is not about the quality of the editors but it is about what it is strategically better to learn in my situation).
What advice would you give me on how to learn using it/them? I know this is a broad question, but it is deliberately so. Have a look at this answer (unrelated topic) for an idea of the kind of information / style of answer I am looking for [but do not feel obliged to answer that way... any contribution will be welcome, in any form!]
EDIT (on picking the "accepted answer")
I picked one answer as the accepted one just now, but I would like to say "thank you" to all those who shared their experience and advice: almost all of it has being useful to me in some way. The thread has definitively exceeded my expectations! Thank you! :)
I would advise that checking out both is worth the time because of various reasons already covered by other answers or "Emacs vs vim vs XY" threads.
Still if you would have to pick one of them I'd go with vim because of one thing:
Availability
Vi(m) has the advantage that it is installed (not only available) by default on almost any *nix system. So no matter whether it is your system or someone else's or whether you are allowed to make changes to it or not, your favorite text editor and friend is there waiting for you.
Once you know vi(m) it feels awesome in those situations where you ssh into a machine and need to do something with text (navigating through a file, editing, whatever). You are going to feel like a King. I remember several times when I almost freaked out because nano or pico were not installed and I had to use "this ugly beast vi" which made unpredictable things when I started typing (because I wasn't in insert mode and didn't even know what that was) and when I was happy to have googled that ":wq!" gets me back out of hell. Now I can look back and smile about it.
I have the general feeling that vim
and emacs are not the kind of editor
you learn by "playing with it" though
Vim and Emacs are certainly editors that you "learn by doing".
Of course the question cries for including these highly scientific text editor learning curve graphs =)
Vim might be a bit harder in the beginning because its modal editing can feel quite unfamiliar at first. I think motivation is the key here. The article "Why, oh WHY, do those #?#! nutheads use vi?" explains the advantages quite well I think. In my opinion it really is worth to give it a try even while the learning curve might be steeper than with other editors and it sounds like you bring the necessary motivation.
Back to learning by doing.
Something I wish I would have done the first time:
Check out Vimtutor. It is an interactive tutorial which demonstrates the power of vim by showcasing it's basic commands and how they can be composed. Just type vimtutor in your terminal.
This helped me to really "get it" after trying to learn editing with vim several times in the past. The tutorial eases the learning curve dramatically as it explains the commands and makes you actually perform them so they become a habit. It really makes a difference compared to being frustrated because of feeling handicapped. Using vimtutor you also will see what the benefits of modal editing are and instead of fighting or ignoring it you are going to embrace it because you have experienced the advantages at first hand. I guess it would be pretty difficult to learn that all by oneself. So these 30 minutes are quite worth it.
I have the general feeling that vim and emacs are not the kind of editor you learn by "playing with it" though.
My experience with emacs is actually quite the opposite. I tried going through the tutorial, but it didn't seem to help much. The way I ultimately ended up learning is with a reference card and just forced myself to use emacs on my code until I got it correct*. Then again, I do also have a screw loose. Your milage may vary. Offer void where prohibited. You get the idea.
One other piece of advice I recall reading somewhere is to try writing down a list of about 10 commands you want to learn and keep it by you while coding. Once you've mastered those commands, make another list of 10 more. Keep doing this until you've got a big enough chunk of the editor committed to memory.
*Note that the linked reference card is out-of-date. If you google, you can get a more up-to-date reference card.
knowing that I have no prior
experience whatsoever on any of the
two, and that I use and develop
(mostly PHP and Python) on GNU/linux
systems (ubuntu, archlinux), is there
any of the two which would represent a
better option to start with?
I'm an emacs guy, so my opinion should be obvious. That said, you're likely best trying out the one that more people you know seem to use. Having someone who's experienced with emacs (and I'd assume vim) is a great help.
If you don't know anyone who uses either one, choose whichever one you feel is the prettiest or has the coolest name. You won't know enough to know which one you'll like, so you might as well choose arbitrarily.
For vim try vimtutor
I came to Vim when I started using Linux after years of Windows development, and had to do a lot of work on remote systems via ssh. For the first couple of weeks hated it. After that I could not live without it.
Probably the best way to start is to use Vim in easy mode ([g]vim -y), most installations have a shortcut called evim. This runs vim in a mode that is in insert mode by default and remaps keys to the usual Windows ones (ctrl-S to save, ctrl-X to cut etc). You can then use it like a regular Windowsy editor but still access the power of Vim.
There is also Cream which is Vim + a bunch of scripts to make it behave even more like a Windows editor.
I started out using evim and Cream, but found I gradually transitioned to using 100% vim.
Also if you use gvim then most of the functionality is also available through the menus and you can see the keystrokes for the same functionality.
Also read the docs - there are extensive help files available on every aspect. I still browse them from time to time and find something new.
Using VIM, I find the following quick reference card very helpful, especially for the stuff I don't do everyday:
VIM QuickReference
For emacs, you should read the GNU Emacs Manual. Don't try to do everything all at once.
Start with the basic stuff, and then move on to the more powerful features once you're comfortable with the easier stuff.
Some time ago I decided to learn vim beside Eclipse as well because of its powerful textual editing, search and navigation features. But - at the same time - I liked the project handling, code completion, refactoring and debugging features of Eclipse and I did not want to lose them.
Nowadays I use an Eclipse plugin called vrapper which provides me nearly all basic features of vim inside Eclipse without losing any Eclipse functionality. Of course it is not a full-featured vim but it gave me the productivity gain I 'expected' (motions, the dot operator, registers and marks). Also, this plugin can be considered the 'trial' version of vim where you can learn all basic and some advanced stuff within your 'best-known' environment.
There is another interesting approach called eclim. Eclim integrates Eclipse with vim from the vim side so you can use many features from Eclipse within vim.
For learning the basics of vim, this graphical cheatsheet helped me a lot.
I would go for Emacs.
Explicit command name will makes your task easier.
I switched to emacs after I had years of experience with vi and never looked back.
Go with tutorial first.
Hang out at #emacs in irc and people are happy to help you in real time, for whatever more you need.
My advice for learning emacs is to understand that everything is done by a command (written in elisp) that is connected (bound) to the key strokes that you make. The power of emacs comes from being able to write new commands and use commands that are not bound to keys (there are too many commands to bind each one to a command.) as well, of course, read and modify commands that are already in emacs.
Next learn how to use the Help key and how to make a key binding list, then how to search for relevant commands (apropos) and see if they are bound already.
Be ready to take learning diversions into the emacs manual (Help, Read manual, Emacs manual).
One argument in favor of Vim if you know Python is that you can write Vim scripts in Python. See :h python. Emacs requires you to learn elisp.
I find myself gravitating toward Vim for scripting languages like Ruby/Perl/Python/PHP, and for Emacs for languages that are more interactive (Lisp, essentially). If you develop your Python code using an interactive Python shell a lot, Emacs might be good, because you can embed a Python shell right into Emacs. If you write code and run it from commandline a lot, Vim can handle that easily enough via :make or :!.
I really recommend you learn both and pick whichever you like better. They are both worth knowing.
Wow, vi/vim vs emacs, what a temptation...
From a vi-user's perspective...
Always Therevi is on about every unix system ever released, in the default install, and available for Win
May save you from RSIvi uses home-row keys for just about everything, modifiers like control and meta are used only for rarely invoked functions and even shift-key use is moderate. This was probably all just a lucky accident, but don't laugh at RSI. It can happen to anyone, it's seriously painful, it's potentially career-ending, and it's hard to treat.
Starts up instantly.In the past, this was a huge advantage over emacs. Emacs users had to start up just once, and navigate everywhere within emacs. Today it starts faster, but in vi, it's perfectly reasonable to quit out of it entirely on every compile or test cycle.
Has an awesome line-mode The line mode in vi is backwards compatible to the original Unix ed(1) program, an editor that had only a line mode. That is, vi's regular-expression-substitution-engine-/-line-editor was once an editor all by itself.
Easily scriptableGot something you want to do to every .whatever file in your project? It's easy to write a declarative script that will edit a sequence of files. No need for imperative or procedural programming.
Easily extensibleVim, at least, can be extended in Python.
First of all, be humble.
As long as you remain aware that they are very powerful tools you'll be ok. If you are finding a task very difficult, and you are thinking 'it's just me that sucks not the editor', you're in the right mind to learn and improve.
Bram's 7 habits are a good tenets to go by
http://www.moolenaar.net/habits.html
Also I highly recommend having a go at writing a plugin. It doesn't matter what it does. It gives you the impetus to dive deep into the manuals.
Maybe, a good way is to learn vim/emacs while using eclipse. Try vimplugin or emacsplus plugins for eclipse.
This should really just be a comment, but against which answer ...
With Vim I'd suggest using the GUI version for a start, just dive in, the built-in help is excellent (:h and the screen splits adding a panel with comprehensive "hyperlinked" help pages). With vim the only potentially dangerous operation is a write, everything else you do is recoverable per command or edit (undo & redo).
The power acquired easily incentivises the learning.
Here's the way you learn: Start typing. When you hit a point where you want to do something other than typing, look up how you do that. Repeat. It helps to start with a few basics, say 7 fundamental commands. Other than that, when you run into wanting to do some operation, look it up and use it.
This great Tutorial was a big help for me for my first steps in Vim. It is a gently introduction and explain at the same time the philosophy of vim in a pleasant way:
aByteOfVim
The way I learned emacs was mostly by doing both of the following:
All the GUI menus show you the key-bindings you can use to execute the same command as that menu item. Pay attention to the bindings for the menu items you select a lot, and try them out manually next time you get a chance.
ctrl-h ctrl-h (think "Help! Help!") brings up a buffer that shows the various types of help available. If you then hit the "b" key (the buffer calls it "describe-bindings"), you will get a list of all the key bindings that are available in the buffer you are working on. Just peruse that every now and then with an eye for commands that look useful. Try them out when you get a chance.
As for vi, I learned it in the days before vim, so I pretty much had to use man vi to figure it out. Most of us emacs users will tell you that all the vi you need to know is :q! ("quit, and I really mean it"). :-)
But in truth if you are a Unix user you need to learn at least enough vi to do simple edits to config files and save them. You never know exactly what (if anything) you will get when you try to start emacs on a strange system Unix system, but vi is always there.
Nearly everything you see or interact with in Emacs can tell you about itself -- you just need to know how to ask it.
To learn Emacs, learn about the current Emacs context: what the values of things are, what the relations between them are, how they are denoted, how you can change them or otherwise interact with them.
The most important thing to learn is that Emacs is Emacs Lisp -- it is a Lisp ecosystem. Learning Emacs means also learning Emacs Lisp -- the more you know, the better. Lisp is the most flexible and most powerful way in which Emacs realizes itself as "the self-documenting, extensible editor".
Icicles can help you learn Emacs and Emacs Lisp. It helps you ask Emacs about itself. This page gives an overview of the ways it does that: Emacs Newbie with Icicles.
Don't get caught up in the vi(m) versus emacs religious war. They are both great editors. I originally started with VI (real VI not VIM) and later started using Emacs. These days, I tend to use both, but emacs more because emacs has some features I need which are not in vim.
The real challenge and what you should be aiming for is how to be as efficient, quick and accurate as possible with your editor of choice. Both VI and Emacs have a lot to offer in this respect. However, much of it boils down to two main habits you need to develop
Don't use the mouse. Both editors were created when mice were not the plague they are now. When it comes to editing, cutting, pasting, highlighting etc, both editors offer keyboard equivalents. Use them and keep your fingers on the keyboard. You will be surprised how much faster you will become
Avoid the arrow keys. This is for a similar reason. The arrow keys tend to make you move your hands off the main keyboard. In the end, this also slows you down and makes you less efficient. Both editors provide far more convenient functions which are faster.
These are the two main things to focus on when learning either of these editors. There is lots more, but to start with, just start with focusing on using the main keyboard.
After you have got that down pat, then begin to think about how you can tweak your environment to suit your needs. By this time, you will be familiar with the power of the editor you have chosen and will probably have some ideas. Both of these editors are very configurable. I find emacs is the most configurable, but you can easily get lost iin writing elisp to configure things and before you know it, your an elisp programmer who does a bit of PHP and Python. To some extent, the same can happen with VIM, but to a lesser degree. However, note that the defaults have usually been set by people with lots of experience and who probably know something you don't. Avoid making the mistake of trying to modify either editor to be what your use to. Learn how it works with minimal config first and then change once you have an idea of why it was done some way - know the rules before breaking them.
If your serious about programming, your editor will be your most important tool. Other important tools are your screen, your chair and your keyboard. The rest is incidental.
Locked. This question and its answers are locked because the question is off-topic but has historical significance. It is not currently accepting new answers or interactions.
Right up front: I do not want to start a religious war.
I've used vi for as long as I can remember, and the few times I've tried to pick up Emacs I've been so lost that I've quickly given up. Lots of people find Emacs very powerful, however. Its programmability is somewhat legendary. I'm primarily doing Solaris+Java development, and I'd like to ask a simple question: will my productivity increase if I invest time in getting my head around Emacs? Is the functionality that it offers over Vim going to be paid back in productivity increases in a reasonable timeframe?
Repeat: I don't want a "my editor is better than yours" answer. I just want a yes or no answer as to whether it's worth investing the time or not. Will my productivity really increase?
[Disclaimer: personally, I prefer Vim. Disclaimer disclaimer: read on.]
Vim excels in the small: by making motion and action separate concepts and providing facilities for complex repeats, you can perform incredibly powerful editing operations in just a short sequence of keystrokes. You can easily do things in Vim in the normal course of editing that would require you to drop down to scripting in Emacs. Also, most of the power you use comes out of the box, so even if you have extensive .vimrc customisations, chances are you will be able to work productively with any Vim installation.
Emacs excels in the large: by mapping all of its UI concepts directly to basic constructs and concepts in Elisp, it becomes very easy to globally introduce features for specific kinds of files or circumstances, making Emacs something like a text-based and much more structuredly programmable form of Excel. This presumes that you are going to spend a lot of time customising your environment for personal needs and preferences. Of course, Emacs does do its best to make it easy to stay inside that one environment for everything and anything you may want to do.
Ultimately, neither is superior. They offer different styles, and depending on your proclivities, one or the other will suit your personal needs and way of thinking better. It is always helpful to know both (plus more editors), of course. But you aren’t going to be appreciably more productive this way or that.
I prefer emacs to vi, but I'm comfortable in both.
There are some things that you can do in emacs that make it more powerful than vi, but not all of them are even programming-related. (Can you send email or read news from within vi? No, but who cares?) If you're comfortable with lisp (I'm not), you might be able to write add-ons and modes and stuff to make your life easier, but that's just likely to be syntax colouring and brace matching and eye candy like that.
I will stop rambling now. Will your productivity increase using emacs? No.
Update: See my comment below. Since I posted this, I have come across ways that using emacs has made me more productive than using vi.
vi is a kitchen knife.
vim is a really nice, sharp, balanced chef's knife.
Emacs is a light saber.
Most of the time, my job requires me to chop vegetables. Occasionally, I have to take on an entire army of robots.
I've been using Emacs for 20 years. I'm typing in Emacs right now with a widget called "It's All Text" that lets me suck text in and out of text boxes in Firefox. I can go really fast in Emacs. I am significantly less productive without it.
This is highly debateable, but I also think that learning Emacs can teach you a surprising amount about programming.
Depending on how you code, you may see a productivity increase. For background, I'm also a long-time vim user, but I learned emacs about 2 years ago, and now use them interchangeably.
What drove me to the point of actually learning emacs was its useful ability to have a large number of files open at once, and to easily switch between them. I was in the middle of introducing a feature that added and touched a large number of classes. (This was C++, so there were typically two files per class.) Since I was still firming up the interface, I would typically be in the middle of updating one file when I would realize that I needed to change another.
With gvim, it was easiest to open a new window for each file, which was starting to get unwieldy. With Emacs, though, it was simple to open a new file in the same window (Ctrl-x, Ctrl-f). Once Emacs has a file open, it's very easy to switch back and forth between the open buffers (Ctrl-x, Ctrl-b).
Taking that one step further, a single emacs session may open many windows, so in addition to splitting the window vertically, I could decide, without interrupting work on a file, to open another next to it, letting me effectively work side-by-side while still keeping each window at the default 80-character width.
There are still some things that I find easier in vim (e.g. block-select mode, simple macro recording, diff mode), and things that are easier in Emacs (line alignment, file/buffer management, window/screen management). Therefore, I find myself alternating between the two (and sometimes using both simultaneously), depending the editing task I anticipate.
If you're still unsure, I'd suggest trying it out. Run through the Emacs tutorial and then use it to write code for a morning or a day, leaning heavily on the help. If you still don't like what you see, stay with vim. Regardless of what the editor brings to the table, your familiarity and knowledge of the tool will by far be the most important factor in your productivity.
I don't want a holy war, but please answer a highly subjective question with a yes/no answer.
Yes, you may see a productivity increase because of the powerful functionality.
No, you will not see a productivity increase because the patterns and metaphors used in emacs may not align with you brain.
The short answer to your question is, "YES". More detail below.
I used vi almost exclusively from about 1980 to 1991. The only time I didn't use vi was when I was dealing with a minimal install of Unix that was too small to include vi, so I had to drop back to ed which is the minimal subset of editing functionality that the original vi was built on top of.
From about 1985 on, other programmers where I worked were constantly singing the praises of emacs. But every time I'd try to learn it I wouldn't get very far. I'd spend an hour going through the emacs turorial (C-h t) and by the end of it all I'd know would be how to insert and modify text and move around the screen. I could do so much more with vi than what I'd learned in that hour with emacs that I couldn't make the switch. Three months later I'd find time to spend another hour and I'd end up going through the same material. Emacs has a Learning Curve with a capital "L". It wasn't until I was doing a contract where everybody else used emacs that I eventually decided I needed to devote more than an hour at a time to learning it. After spending a little over a day doing nothing but working through the tutorial and the included documentation, I finally got to the point where I could do things with emacs that I couldn't with vi. From then on, I've never wanted to go back. I can still type vi commands in my sleep, but I can do so much more with emacs.
Understand that I'm comparing emacs and vi, not vim. I've never learned the extensions that vim has added to vi, and it's likely that many of them are features copied from emacs. If so, and if you're already proficient with vim, emacs may not hold as many advantages for you.
Among the things I depend on all the time in emacs are:
When you use emacs, everything's treated as text. This means that you can manipulate any data in any buffer with pretty much the same commands. And in cases where a buffer's in a mode where some of the standard commands are unavailable, you can copy text to another buffer running in fundamental mode and use the standard commands there.
Emacs provides a multi-"window" environment displayable in on a character-cell terminal. In the days before bitmapped graphics and real windows, emacs was written to simulate window-like behavior using nothing but ascii characters and cursor positioning. You're probably thinking, "That's ancient history. Why should anyone care about that today?" I still use that capability every day. I use a webhosting company that allows me SSH access. So I can log into a Linux host across the Internet and run shell commands. While that's pretty powerful, it's far more powerful to be able to divide my terminal emulator up into "windows" using emacs, run shells in several of those "windows", edit files in other windows, and view and edit directories in still other "windows".
Actually, when I said "window" in the previous paragraph, I really meant "buffer". Emacs' character cell emulation of windows is a way of dividing up the screen real-estate. An emacs buffer is associated with content (a file, a bash shell, a directory, arbitrary text not associated with a file, etc.) which may or may not currently be displayed. To view what's in a buffer, you pick a window and tell it what buffer you want to see. So you can be working on way more things than you have space on the screen to display. It's roughly analogous to what you do in a modern bitmapped-graphics GUI when you iconify/de-iconify a window.
I've already alluded to the fact that you can run a shell inside an emacs buffer. You can have as many buffers running shells as you like. You can copy and paste text back and forth between a shell buffer and a text file, or compare a portion of text between a shell buffer and a text file using the exact same keystroke sequences you would use to copy text or compare text between two different text files. Actually, this is true for most types of buffers, not just shell buffers and buffers associated with files.
When you use emacs' command to open a file, but what you've selected is actually a directory, the buffer runs in dired (directory editor) mode. In this mode, a single keystroke will open whatever the cursor's currently pointing at, be it a file or subdirectory. A buffer in dired mode is a file manager - a character-cell terminal oriented analog to Finder on the Mac or Windows Explorer.
One of the emacs functions I use almost constantly is "compare-windows". I greatly prefer this to command-line "diff" or GUI comparison tools like what's built in to Eclipse. Diff or Eclipse compare entire files, and show you which lines differ. But what happens when you have two different lines that look very similar? Consider the following:
What's the difference between this line and the other?
What’s the difference between this line and the other?
How long would it take you spot the difference? (Hint: ASCII and Unicode apostrophe look pretty much alike.)
Unlike diff and Eclipse, which just show the lines that differ, emacs' "compare-windows" function is interactive. You position the cursor in each of two side-by-side windows at a point where the window contents are the same. Run "compare-windows", and the cursor in each window will move to the first character that differs. Reposition the cursor in one of the windows to the point where it's the same as the other window, and rerun "compare-windows" to find the next difference. This makes it easy to compare subportions of files.
Another thing I regularly use "compare-windows" for is comparing checksums. Many software projects distribute a tarball of the application on a page that also includes an MD5 hash of the tarball. So, how do you compare the MD5 hash on the distribution page with the MD5 hash computed from the downloaded file. Emacs makes this trivial.
First copy the MD5 hash from the webpage into a new emacs buffer. Then, after downloading the .tar.gz file, run:
md5sum downloadedfile.tar.gz
in a shell buffer. With those two buffers displayed in side-by-side emacs windows, position the cursor in each window at the beginning of the checksum and run "compare-windows". If they're the same, the cursor in each window will be positioned at the end of each checksum.
In the previous point, I gave the example of running "compare-windows" on the lines:
What's the difference between this line and the other?
What’s the difference between this line and the other?
"compare-windows" will leave the cursor positioned on the apostrophe in each line. So, now you know which characters differ. But what characters are they? Type the two keystroke command CTRL-x =, and emacs will display the character, its ascii value in octal, decimal, and hex, the character offset from the beginning of the file, and the character offset from the beginning of the line. Since ASCII is a 7-bit encoding, all ASCII characters have their high-order bit turned off. Once you see that the value of the first apostrophe is 0x27 and the second one is 0x92, it's obvious that the first one is in the ASCII character set and the second one is not.
Emacs was one of the first IDEs, perhaps the very first one. It has modes for specific languages. I find them handy for imposing consistent indentation on my code to make it more readable. There's also built-in functionality for compiling and debugging code. I don't use the compiling functionality that much because when I was writing for a compiled language like C, I was used to doing that at a shell prompt. The debugging functionality was very nice for C and C++. It integrated gdb with the editor in such a way that you got pretty much the same functionality as the debugging capabilities now in Eclipse, but didn't waste screen real-estate the way modern GUI-based IDEs do. Theoretically the debugger integration should be easy to make it apply to virtually any other language, but I haven't checked to see what other languages it works with nowadays.
Emacs allows you to create macros by telling it when to start remembering what you're typing and when to stop. This is extremely powerful for tasks you frequently do.
Emacs is infinitely extensible if you know Lisp. But even though I've never learned Emacs Lisp, I still find Emacs one of the most powerful tools I've ever used.
Emacs key-bindings. I'll be the first one to admit that Emacs key-bindings suck. But it's so much more powerful than anything else I've used, that I'm willing to put up with the key-bindings.
In a humorous vein, years ago Emacs' author Richard Stallman (also originator of the GPL, founder of the GNU project and founder of FSF) lampooned those who treat vi vs. emacs as a holy war. He invented the character "Saint IGNUcius" of the Church of Emacs. In that guise, Stallman commented, "Sometimes people ask me whether it is a sin in the Church of Emacs to use the other text editor vi. Well, it's true that vi vi vi is the editor of the beast, but using a free version of vi is not a sin, it's a penance." (See http://stallman.org/saint.html. There's also a cute photo of him, but since I'm new to StackOverflow, it won't let me post more than one URL. So go to the same domain, but fetch the file saintignucius.jpg)
I used Vim for 10 years leading up to delving into Emacs 2 years ago. I have a reasonably fresh recollection of just how my productivity curve modified over time.
My points are all conditional, YMMV depending on your strengths and experience.
If you have used Unix and the command line long enough that you are familiar with C-a, C-e, C-n, C-p, C-k, C-y, etc as they function on the shell, it will not take long to transition to using those same bindings (the defaults) in Emacs. I recently discovered that XCode uses these bindings as well.
If you are comfortable with an always running editor, tending buffers (like you would browser tabs) and thus living in the application (like you would with Web2.0 apps in the browser), Emacs will likely show immediate productivity enhancements.
If you generally work in projects of many related files, this persistence pays some added benefits in maintaining context to that buffer. Each buffer is contexted at its open file allowing for convenient use of various productivity boosting tools for your that project (like grep-find, eshell, run-python and slime). This coupled with text completion, yasnippets, etc start to look a tiny fraction like an IDE although ad-hoc and heavily individualized by your configuration. This is apart from more civilized Emacs IDE-like services like ECB.
My productivity took a hit initially as I typed "jjjkkk" constantly Esc-Esc-Esc-Esc for the first week or so. The following week I cautiously started using the right navigation keys. Then I discovered the configuration file... Honestly, if I had had Emacs Starter Kit from the start, I would have said my productivity slowly worked back to parity over the 3rd-4th week but I did go down the config file rabbit hole. A co-worker of mine, though, has just transitioned from vim to emacs and he just grabbed the Starter Kit and he is on his way. First week in and he seems comfortable and enjoying all the surprise benefits (that sensation will probably last a decade).
Finally, if you make mistakes you will immediately gain productivity (and confidence) from the circular kill/yank-ring and undo-ring. I am also personally a fan of region specific undos.
My short answer is Yes it is worth taking 3-4 weeks of a diminishing productivity-hit to learn Emacs. Even if you decide you prefer a streamlined unix utility combo over Emacs for development you will derive from it an education widely applicable beyond the editor.
Emacs documentation is a forest. I came from Emacs to Vim when I realized how organized Vim's documentation is, and how chordable many of the features are. I don't know what lies down the path of an Emacs expert, but I will warn you that learning to do anything useful in it takes a long time, and won't make you any better at nethack. Stick with Vim.
Textmate is a better Emacs for Macs, though that won't help you with Solaris. Eclipse is kind of cool, and has a lot of plugins.
Emacs will provide a productivity gain if you're willing to learn and customize it to fit your needs. Most people are not. To increase your productivity you must use the tool for more than simple editing - most people never progress past simple editing.
Here's a quick test: have you customized your window manager to make your environment more efficient (tailored to fit your needs)? If 'no' then likely you will not get the ROI by learning emacs.
That being said, if you're developing Java, Eclipse is the standard answer, so your question is pretty moot.
I was very happy with my Vim, but once I heard of org-mode, I started learning Emacs.
org-mode could be one strong reason to learn Emacs.
I love emacs and use it every day.
That said, I don't think the cost of learning it will be recouped by productivity gains down the road.
If you're programming Java, you need a good IDE. Emacs goes a fair way towards being one, but let's face it, IDEA et al beat it hands down. (emacs probably inspired a lot of those IDEs, but that's another story).
Twice I've tried to learn Emacs. It just doesn't fit how my brain works, and so I don't use it.
Emacs (or vim) is not significantly better than vim (or Emacs). Both have many options to add to them that allow them to do amazing things. I have no doubt that anything you can get done in Emacs you can also get done in Vim, just not standard.
Try Emacs. See if it fits better. It's a no-lose situation.
I want to look into emacs further, but I just can't use it for long stretches of time; it hurts my hands. Am I doing something horribly wrong?
vim and emacs, they are THE most capable editors and have been for quite some time.
If you know one really well, I doubt that you will gain that much in the process...
However, it is always a good idea to look into what plugin that are available since
a couple of new plugins can do wonders for the productivity.
/Johan
No (and I've used both).
Along the same line of not looking for a religious war (but go ahead and downvote me if you feel you must), why do you feel that the only option to vi is emacs? Is it the OS you develop on, or just the options you explored?
The Java development landscape enjoys some of the best IDEs these days (both free and paid for), if not the best when it comes to code editing and refactoring support.IntelliJ IDEA even has a vi plugin that can help you feel more at home, for instance (not sure if something similar is available for Eclipse). While changing tools does imply a learning curve, the time spent doing it might be worth it if the leap is big enough.
How fast do you type? If you hunt and peck, then emacs is not for you. If your fast tho, it can help not having to grab your mouse all the time.
Generally, emacs is more powerful than vi. You could do a lot more things in emacs.
You're productivity will increase if you decide to put the time in to program your text editor. Of the two editors, emacs presents a better framework or constant customization. If you don't program your text editor, just stay with what is comfortable.
One good reason to learn Emacs is because other programs use Emacs keybindings too. You can use Emacs keybindings at a bash prompt, for example, or anything else using GNU readline. It's good to learn the basic movement and word/line deletion and undo/redo chords in Emacs so that you can use them in other programs. Your productivity will increase in those other tools even if you never use Emacs again.
I know Vim and Emacs, and Vim fits my brain and my habits better. But other people claim the same about Emacs. You never know for yourself unless you try. It doesn't take that long to learn Emacs well enough to see whether you're going to like it.
Will my productivity really increase?
For the first few days/weeks, absolutely not.
After you stop having to read through the tutorial every time you want to edit something - sure..
Emacs is more "powerful" than vim, it's scripting engine is far more flexible, and there are far more scripts, modes and the likes built around emacs.
That said, the opposite is true.. If you spent the same amount of time improving your knowledge of vim, you'd could be just as productive..
Maybe not productive in the same way - I'd say vim is quicker for editing files, emacs is better at doing everything else (again, I would personally say things like flymake-mode, VCS bindings are such are quicker to use than the vim equivalent)
I agree with Alan Storm: "because the patterns and metaphors used in Emacs may not align with you brain"
This is a very important factor. Different brains adapt differently to different interfaces.
Some of the main - and easily available - features I really love Emacs for, and I count as productivity enhancers:
1. "yank-pop" facility - every cut/copy is saved into a stack so you can later choose which to paste (don't know if vi / Vim has this but most Java IDEs don't)
2. the Ctrl-key navigation mapping - this allows you to navigate your file without moving your hands off to use the arrow keys. (key-binding in other editors helps of course)
3. available on almost every platform (true of vi/Vim too of course) - whether GUI- or text-based (Java IDEs are available on most platforms too but only in GUI mode, and are significantly larger and need to be installed separately whereas Emacs is generally more widely available - BSD / *nix / Linux / Mac systems
4. I prefer my editor to stay out of the way until I need it - Emacs' spartan display forces me to think before I type.
5. The basic navigation keys in Emacs are kind of universally available - on my Mac OS, I can use these keys in terminal, mac mail, etc.
Ultimately, if Emacs' philosophy appeals to you, you will put in the extra effort to learn it. And it will reward you.
Since vi/Vim and Emacs are pretty close in terms of what they can or cannot do, productivity with these two editors comes from experience in using it.
In my opinion, being a programmer it won't take you long to get the general idea about Emacs once you start using it. Others can only say so much, you got to try it out for yourself to know it.
As for me, I use both. It's like taking more than one weapon to a war, use the right one in the right circumstances. ;)
I like Emacs, you can extend it by your needs- in my eyes, any system which you can extend by yourself is award-worthy.
Disclaimer: I'm ignorant. I've been an emacs user for about 4 years, and vim user for about 6 months, maybe more like 15 if you count all the times I've tried to learn it and hated it. (The writing vs moving mode distinction kills me. Every time. So if it doesn't kill you then my opinion might be completely worthless.) That said, I think my opinion is actually interestingly different from the 26 others that I've seen on here, so I'm going to voice it.
:Disclamer
My opinion:
Emacs is better for typing, especially large-scale "I'm writing a new feature and it will be a while before I even try to see if it runs".
Vim is better for editing, especially quick edits.
When I need to understand and hack in 8 files simultaneously, Emacs' properties as a tiling window manager with multi-buffer (buffers have a 1.2:1 correspondence to files, they're often the same thing, but aren't necessarily) regexp-search (and replace) are incredible.
If I don't like some small thing because of git diff in the shell (I don't use emacs' VC features very often, although when I do I love them) I open it with vim and get the hell out faster than I could hit Alt-TAB.
The fact that Emacs' editing commands are more readily available while typing make typing much faster than it is in Vim. Ctrl+a is much faster than ESC ^ i, and you don't have the cognitive load of "do I want a or i or o or O..." which, god, I hate thinking about. And same for all the other movement commands commands.
I type faster, much faster, in Emacs. That means things like Org Mode (which I use for everything: TODO lists, bug tracking, notes, long emails, documentation...) make more sense (to me) in Emacs than they would in Vim.
And, Elisp is incredible, even though it sucks. It totally makes up for Emacs' broken regular expressions: you can use the full power of emacs everywhere, including in a multi-file regexp-replacement. And in text snippets.
If you are concerned about the health of your hands choose Vim.
I suffered from a bout of RSI in the past, and I found one of the main culprits was "chording" i.e. holding down many keys at the same time. Emacs uses chording extensively whilst VIM uses single letter commands chained in quick succession. This puts much less strain on your hands as the muscles don't have to twist and contort to perform commands in the editor. Injury due to RSI can ruin your productivity so in your calculations be sure to account for this.
I really see no reason to switch. I've used vi for a long time and am quite comfortable with it; about every six months I would install emacs to give it a go, then quickly just switch back. Yes there were things I much preferred about vi, but the main reason I never stuck with it is because the time investment to fully learn another editor when I already know an extremely capable one isn't worth it.
I'm reminded of this rather dated study.
In my opinion, SLIME is about the only reason to switch to emacs if you're already proficient with vi.
No
I've been using emacs for years, I'm a convert from VIM, and I love it to bits.
But any productivity gains from having a better, programmable editor will be totally wiped out by the enormous amount of head-fucking that it takes to get the hang of emacs. It was designed as a console editor, and its idea of interface is not yours.
And even when you've got it completely, your extra productivity will mainly be expressed in the extra emacs lisp you can write.
Who cares? It's great fun, and lisp is the dogs! If you want to 'get things done', then forget about programming. You can always hire programmers to 'do' 'things'.
The only circumstance under which I'd recommend learning emacs for productivity reasons is if you're a lisp/scheme/clojure programmer. It makes such a good lisp environment that then the few seconds it will save you every time you want to do anything will quickly add up to a real gain. And elisp (which stands in relation to lisp as excel macros stand to ALGOL) will seem much less alien if you already use a real lisp.
If you do give it a try, use it on a virtual console where it feels more like a sane way to arrange an editor. Only when that makes sense try to use it under a window system, which will fight with it.
In an earlier answer, Aristotle Pagaltzis wrote: "Vim excels in the small ... You can easily do things in Vim in the normal course of editing that would require you to drop down to scripting in Emacs."
I switched to Emacs after over a decade of exclusively using vi, and initially I would have agreed with the claim, "You can easily do things in Vim in the normal course of editing that would require you to drop down to scripting in Emacs." But then I discovered that by using Emacs' macro capability and a large repeat count, I could easily make Emacs do pretty much everything that vi had made easy, and a great deal more.
Emacs' macro functionality involves three commands:
C-x ( start remembering keystrokes
C-x ) stop remembering keystrokes
C-x e replay the remembered keystrokes
For example, in vi if I wanted to find all <a> tags in an HTML file
and add a target attribute, I might do something like the following:
:g/^<a/s/>/ target="_blank">/
This example is not perfect, since it assumes that all <a> tags are on a line by themselves. But it's good enough for illustrating how one accomplishes the equivalent task in two different editors.
To achieve the same effect easily in emacs, here's what I do:
1. C-x (
2. M-C-s <a\>
3. C-b
4. C-s >
5. C-b
6. target="_blank"
7. C-x )
8. C-u 10000 C-x e
Here's a description of what each keystroke above does:
1. start remembering keystrokes
2. regex search for <a. Note that the "\>" after the "a" is not HTML. It's emacs regex notation for end-of-word.
3. back up one character - as a side-effect this gets you out of search mode
4. search for the next ">"
5. back up over the ">"
6. enter space as an attribute-delimiter followed by the target="_blank" attribute
7. stop remembering keystrokes
8. replay the remembered keystrokes 10,000 times or until the search fails
It looks complicated, but it's actually very easy to type. And you can use this approach to do lots of things that vi can't do, without ever dropping down to Lisp code.