I have been writing code so far in conventional text editors that come with the OS so far or use an IDE in some cases. I know there are some advanced text editors like Emacs and Vim available solely for the purpose of coders. How important are they really, should a programmer dealing with PHP, Pyhton etc. learn these editors? What are the advantages that they provide over conventional editors like Notepad++, Scribes etc..
|
|
||||
| show 4 more comments |
|
Vim is a really good tool once you familiarize yourself with it. It starts up faster than any IDE or text editor I've used, and it has syntax highlighting and it indents the code correctly in most cases. It also helps you focus on the coding process itself, you won't be using the mouse at all to deal with it, that'll save you a lot of time when you're just writing code. It has a wealth of plugins for whatever it is you're doing, as well. I haven't used emacs to be honest, but I'm sure there are people here who like it, I personally don't like having to press Ctrl or Alt all the time. Edit Vim's usefulness also depends on what you're writing. If you're an API developer (Java, C#...etc) you'll most probably be more comfortable with an IDE. But if you write scripts (Bash, Perl...etc), Vim might be the way to go, since you need to write something fast, Vim is fast, and does everything you need. |
|||||||||||||||||||
|
|
A programmer should not necessarily learn a lot of tools, but learn a few and learn them well. Emacs and vim each have their distinct strengths but unless you use them a lot on a regular basis you will not benefit enough from them, I think. Especially not if you are a learning programmer. You will, however benefit from a good IDE, but you should also be able to do real work just given a plain, simple editor. |
|||||||||||||||||||||
|
|
Importance of |
|||||||||||||
|
|
Are you a fast touch typist? Do you often wish for more keyboard shortcuts to make edits? Does the time you spend editing interrupt your train of thought? Do you find little things about your editor that you wish you could customize to work just the way you like it? Do you not mind spending potentially a lot of effort up front if it means it will save you more time and effort in the long run? Are you unbothered by people considering you anachronistic? If so, then vim may be a good fit for you. Do you prefer to be able to figure out your editor without reading the manual, even if that means fewer features? Are you more comfortable using what everyone else in the office is using? Do you use the mouse for everything? If so, then vim may not be a good fit for you. |
|||||
|
|
"Must a programmer learn text editors like Emacs and Vim?" No. I feel obliged to qualify that, but actually it doesn't need it. So I won't. |
|||||
|
|
No If you want to learn how to use them, don't do it in a production environment. Do it on your downtime or time set aside specifically to get used to writing code on them. When you get more experience, introduce it to your environment but keep the program you are used to near by. I kept frontpage near by when I decided to transfer to a pure text editor, until I was confident enough that I no longer needed it. |
|||
|
|
|
I think that learning Emacs (and probably Vim as well) is very useful. Why? Simple: I can use the same exceptionally capable editor for more or less everything I do. This is great because I am a student, constantly learning how to use shiny new things. This year, I played around with Haskell, did a ton of JavaScript, used Scheme, wrote some Java, screwed around with Perl, worked on a web site... Emacs was great for all of this. In the past, I had some problems with different languages: I would pick up Perl or Python, but could not find a good editor for either. Now, I know I can always use Emacs. Of course, sometimes Emacs does not have all the features I want, but it always has enough features off the bat to use for quick projects. For longer projects, it may need some customization, but the time taken to do that is probably equal to getting and learning a new IDE. In short: Emacs is great because it supports so many different languages, and is powerful enough even without support for a specific language to make life much better. |
|||
|
|
|
Nowadays popularity of various kinds editor worship most likely comes from Pragmatic Programmer book, or, to be precise, from readers who mindlessly crammed Chapter 3 Basic Tools -> Power Editing -> One Editor but totally missed the key (pragmatic!) takeaway laid out in Preface chapter:
If one gets the general understanding like above, this alone makes the book worth reading. Main idea to keep in mind is one that authors stated clearly and unambiguously, "there is no such thing as a best solution". |
|||
|
|
|
There are at least three reasons why a newly minted programmer might choose to spend some time learning emacs and vi:
Now then, is it important to learn vi and/or emacs? I'd say that it's useful to know something about both of them, especially so that you know at least a bit if you ever find yourself needing to use them (you might). But not knowing them won't necessarily hold you back. It's much more important to know how to wield the tools that you use daily as effectively as possible. * That's not a typo -- you'll get it after you spend your first hour with vi. |
||||
|
|
|
Neither emacs nor vi are solely meant for coding; they just happen to support features that make writing code a little easier. vi's sole virtue is its ubiquity; any Unix or Linux-based system is going to have an implementation of vi. It's light-years friendlier than TECO was, but so's using an Etch-a-Sketch. That said, vi is my primary editing tool in a terminal session, simply because I never had the bandwidth to learn it and emacs at the same time (and emacs has too damned many keycode combinations). You don't need to learn either tool; there are other quality text editors out there that support many of the same features in a friendlier format. |
|||||||||
|
|
If you need to learn an editor for programming, make it emacs. Why? If I need to make an rpm and I open emacs, and tell it to find a file which happens to end with the extension .spec WHAM! A skeleton file appears with all the tags and macros already filled in with text color-coded. And if I want to submit to my favorite version control, esc-x load-library mercurial (or git or svn) puts emacs in the mood to drop down the right commands from its version control menu or to recognize the commands like ctrl-x v v to check in or out code from a repository, and to do everything one can do with a repository. Optic fatigue occurs when one stares at the same colors for too long. I use konsole for terminal windows and change the colors frequently. With emacs not in a terminal window, I have more than 50 color themes to choose from, some of them comfortably low contrast, like Alice Blue, and some eye-stabbing like euphoria for when I need to stay awake. I code a lot of python. When I need to test some coding for syntax, I don't leave emacs. I start the Python interpreter, and the screen splits, then I save my python file and import it to the interpreter to check syntax--an error will be readily apparent, and I can fix it immediatelty. When I am done, I can switch to an unsplit window and continue work. Some folk say use vi, and I do use it on some older SUN systems... I have a regular rhythm--hit i and insert a char then hit escape and hit i again and type the next char... (barely better than ed, but it is what's available). Usually my first install on any new system is zile. GNU zile is emacs without all the window dressing like browsing and email and irc and colors, just a C-coded binary that works in about 100k and uses emacs keycodes. If emacs were as onerous as most try to make it sound, it should be amazing that so many folk were gluttons for self-flagellation by making emacs-like editors. MINCE Is Not Complete Emacs, the 31 flavors of micro-emacs, Jed, Zile, Joe and an oddball python coding or two plus web-based YMacs, are all emacsen. peppy http://peppy.flipturn.org/ is a different take, using emacs keycodes and coded in Python and it will edit nigh on everything, including chunks of binary data, and it has dozens of modes for programming languages, but its keycoding paradigm is emacsen. YEah, emacs is worth learning, and so is vi. Of the rest, maybe Eclipse is as useful, if you can stand the hoggishness of its many inserts. And if you need something REALLY small, lightweight, and fast, check out e3. The x86 version is written in assembler and serves many keycode sets including Emacs and Vi. https://sites.google.com/site/e3editor/ And oh yes, I open emacs, type 17 pages, and BLAP! Lightning strikes and my power goes out. When power is restored, I look at the work and discover I lost the last 7 characters I typed.... And if I decide to follow the "recover crashed session" procedure, I can reduce it to 2 lost. Python code doesn't believe in indentation, it DEPENDS on them. Emacs is aware of that and makes sure your indentation is proper. But if you decide to remove an "if" you will have a whole region in the wrong indentation status. With emacs you fix that by: ctrl-space and arrow keys to highlight the region ctrl-c < to outdent all the highlighted code. (ctrl-c > indents it again, correctly). I think I have used more than 60 editors, and still the one I come back to is emacs, not because I can get function code stubs in C or proper indentation or color-coding, but because I can customize it beyond its already awesome capabilities. Richard Stallman's brainchild was adapted by so many... |
||||
|
|
You don't need to learn Vi or Emacs, you need to learn your tools. Imagine a sniper who doesn't know well the downsides and capabilities of his rifle, he would not be a good sniper ? Would him ? So go ahead and find an editor you like, you might like Emacs, Vim, Textmate, Sublime Text... heck, maybe you don't like any of them and you are OK with Nano, but what matters is that you are comfortable with your tools. |
|||
|
|
|
First things first. VIM is more productive for programming than Eclipse or . Your personal productity in VIM may be abysmal, but the potential cap of VIM is much higher. This is a fact. VIM is a martial art. It feels unnatural when you first use it. And you can't even make it work. It takes years of practice to gradually become productive. You focus on mastering a little detail at first. Slowly all these bits you master add up until text is flowing effortlessly out of your finger tips onto the screen. Complicated edits that would make your co-worker sigh will jump from your hands before he can finish his exhale. There are few people who can use VIM. Fewer who can use it productivley. And you may never meet a master in your life time. But they are rumored to exist. VIM is designed to keeep your hands on home-row. Moving your hand from the keyboard to the mouse is demoralizing. It's a gross motor movement. Moving your arm has a phsycological effect that hurts your motivation. Using VIM, someone could bolt your wrists onto the keyboard and you could still easily open up files, split windows, open tabs, build the project, search/replace, change fonts, change colors, etc. And all at lightning speed. VIM is modal. That means you don't have to do complex key combinations where you hold down control+shift+Key. This hurts your hands in the long run. Instead you execute commands. There is no need for key combos to due to the modal nature. We store data in our memory like computers do. Our memory can only hold a few values at a time. See how many distinct integers you can hold in your head before they start to slip away. We overcome this human limitation by writing stuff down. If data falls out of our memory we can easily look at what we wrote down to get it back. If your time is spent doing gross motor, physical things you are losing time that could have been spent on processing data in your brain. You want your mind to flow onto the screen without any effort at all. It may not sound like much but VIM's ability to effortlessly transfer what is in your mind to the screen is a BIG productivity boost. It's hard to put in words what I'm trying to say. VIM supports code completion. Both textual and look-up based. It can pull text from mulitple files. Anything you desire can be had in VIM. Either make it yourself or use something someone else cooked up. VIM supports goign to definitions with ctags. You can also find all references of an item. Again, anything you desire can be had in VIM. The scripting of VIM is huge. You can download or create thousands of color schemes and change colors in an instant. Try to change fonts or colors in Microsoft Visual Studio and it will hang for 20 seconds while it loads data. It won't let you store color schemes and you must spend 30 minutes tweaking your colors and fonts every time you want a change of scenery. In VIM you can set line spacing to zero to fit more lines of code on the screen. I get over 80 lines. Visual studio uses 2 pixels of spacing for every line and you can't adjust it!!! Less lines = more scrolling = less productivity = forced to use small fonts for more lines = eye strain. Split windows are opened in an instnat in VIM. It's usefull when you need to look at data in one section of the code that's far from the place you are typing (or in a different file). You don't have to spend time resizing windows, or worry about GUI windows overlapping each other and falling behind each other. Un-related code windows can be opened in tabs as to not take up screen space, but allow quick switching. VIM as an IDE: http://www.youtube.com/watch?v=MQy2rVOf-z0&feature=fvwrel VIM the revenge: http://www.youtube.com/watch?v=lQNFfhC4QI8 |
|||||
|
protected by maple_shaft♦ Apr 17 at 11:33
This question is protected to prevent "thanks!", "me too!", or spam answers by new users. To answer it, you must have earned at least 10 reputation on this site.

vimis notvi.vimdoes not have ubiquity on all systems. You can usually findvion most systems, not true forvim. People who learn onvimcan get by invi, but it's really not all that interchangeable. – dietbuddha Apr 18 '11 at 3:46