89 comments

[ 3.2 ms ] story [ 149 ms ] thread
Here's the thing about Vim or Emacs: Nobody can tell you when you need to switch to one of them. Your heart will tell you.
Sometimes your boss will tell you.
I agree with you at least for me thats how it was :) Don't get me wrong both are are great, heck an editor you write yourself in a day will do the job. But since we developers spend so much time with the editor I think it does sort of become a personal thing where you just have a "good feeling" in whatever you use (for me that match was emacs :)
I kept reading about vim, emacs, notepad++ and a bazillion other 'great' editors for years.

No one ever made me quit Editplus.

No one, until Sublime Text, that is.

So that's true, you have to follow your heart.

Q: What's the best way to generate a random string?

A: Ask a first-year CS student to quit out of Vim.

A: Ask a vim user to quit out of emacs.
With your keyboard set to dvorak.
C-x C-c I believe

Keep your friends close, and your enemies closer :)

First-year CS students don't read what's printed on the screen? Good lord how can we expect the average user to do the same?
Ask a first-year CS student to quit out of ed.
From command mode, it's the same, from insert mode you need to know how to get to command mode, so it's harder to get out of vi compared to ed.
Back in my college years, the first time I tried the Vim editor, I couldn't quit the editor, but was knowledgeable enough to kill Vim's process.

And yet, later on, when understood the editor's philosophy, I felt enlightened.

You have to ssh into my machine and fix a configuration file. The only editors on the machine are ed, ex, and vi/vim. You're dead int he water and useless to me. learn the 22 vi keystrokes. It won't kill you. It will make you stronger.

Editors that make me take may hands off the keyboard in order to click around in the gui to move around my files are productivity killers.

I agree. Is it really that hard to turn vim into a regular text editor? Hell it's even easier to use macvim and all you need to know is i and escape to make it behave "normal"
>are productivity killers

Don't state this as if it were fact. They're productivity killer for you. Because you have been using Vim for so long. A person who is balls deep familiar with Sublime Text 2 or Visual Studio will be just as fast due to experience.

> A person who is balls deep familiar with Sublime Text 2 or Visual Studio will be just as fast due to experience.

I wouldn't state this as if it were fact either. The biggest gain for me is the ability to quickly and easily script my text editor to do tasks for me. Sublime Text 2 has a macro system, but it looks neither quick nor easy to write scripts for. Visual Studio looks like it no longer supports macros as of VS2012.

However, there's a huge leap in productivity between having an editor whose keybinds you know (and can use without a mouse), and one which you have extended with extensive macros. That's like the difference between an out-of-the-box Emacs and SLIME.

Your Vim setup is awesome, but for a newbie to vim like me, it'll take a long time before I'm more productive using it -- not only would I need to internalize the keybinds and text processing tools, but I would also then have to start adding custom scripts and stuff, in order to do other things. (run unit tests, evaluate a block of code in an interpreter, etc)

The comparison was between someone who is skilled at vim and someone who is skilled at Sublime Text 2. My argument is that the person using Sublime Text 2 wouldn't be as "fast" as the person using vim, not that the person who was skilled at Sublime Text 2 would be as fast as me using my VIM setup, which is what you're talking about. I agree, that would be a ridiculous argument.
"The only editors on the machine are ed, ex, and vi/vim. You're dead int he water and useless to me."

I wonder how many devs actually don't ever read man pages? Seriously, everyone should know how to surf man and do it well, start with man man.

Bullshit.

I can open a file, search a random string and fix your damn configuration file over ssh using vi/vim.

I will however, keep using Sublime Text 2 over Vim almost every single time, thank you very much. Vim usability sucks.

Also, try to play some Starcraft competitively before dismissing the mouse as productivity killer. In the right hands those bastards are FAST.

Selecting and moving a string from a random part of a line to the middle of another line is faster with a mouse than with keystrokes. Not by much, but it is.

The thing about Starcraft is you don't need the full keyboard. A large part of the "productivity hit" people talk about with text editors is not "mouses are slow", but that switching from keyboard to mouse back to keyboard back to mouse is slow.
Have you tried touchpads? Switching to touchpad takes almost no time.
> Have you tried touchpads? Switching to touchpad takes almost no time.

... but touchpads are relatively much less precise than mice, especially when used with your thumbs. For many activities, this matters (e.g. precision is required to select text in many cases; it can be maddening to have to continually re-select the same text because you keep missing the first character...).

I've noticed many people actually switching to "touchpad mode" for precise movements, where they move their whole hand down and use their index finger on the pad. This seems to increase the accuracy somewhat, but of course incurs the same switching overhead as a mouse...

I always use index finger and don't have problem with precision (I even don't own a mouse). It takes not that much time and comparable with time to click Esc in vi.
It's been a good decade since I've seen an install that didn't also include nano. Linux Server Administration is not "being good at computers" in all cases.
> Editors that make me take may hands off the keyboard in order to click around in the gui to move around my files are productivity killers.

A couple thoughts on that:

1. Allowing you to take your hands off the keyboard in order to click around in a GUI is not necessarily the same thing as making you do it. Even in Visual Studio experienced users' hands tend to stay put. For example, to open up a file to see some other element's code, there's no sense in bothering with the mouse. Not when with a single keypress you can jump not only to the correct file, but to the correct position within that file.

2. On the other hand, needing to consult the manual in order to find out how to do something is often more time-consuming than mousing through a menu. In a well-developed GUI, mousing through a menu is also the quickest way to figure out a new keyboard command. Much quicker than Googling or digging through manpages.

3. Even if you haven't bothered to learn the keyboard commands for your graphical editor, if you're switching what file you're working in frequently enough that the fraction of the second it takes to click on a tab is adding up to anything remotely significant, then you've probably misplaced the blame for your productivity issues. If you're switching files that much, the amount of time you're wasting on mental context-switching is probably immense.

Naturally all this assumes that one is using a well-designed graphical text editor, and sadly the vast bulk of graphical text editors simply aren't anywhere near as refined as emacs or vim. Especially not if you need one that's cross-platform. But let's be careful not to make radios out of coconuts here: The reason emacs and vim are so effective is because they are venerable, not because they are textual.

One of the first reasons I ever heard for learning either vi or emacs was that they were the only editors that were basically prevalent everywhere, regardless what flavor of unix you found yourself on. Not so much because of how powerful they were.
Using vim helped me write better (or smarter) regular expressions. I tell people starting out with vim to stick with it and it will help them in the long run.
I'm finding more and more often that the best way to teach someone about a feature of their own favorite text editor is to threaten to walk them through doing it in vim. Magically, they've found the plugin or option before I can make it back to their desk with my solution.
(comment deleted)
I teach high school math and science and once a year I teach a programming class, which currently focuses on Python. I then mentor a few students who are interested in following up on the class on their own.

My preferred editor is emacs, but there is no way I'd try to have people use emacs in their first programming class. We are using Ubuntu computers, and I am currently having students work in Geany.

Are there any other suggestions for editors on ubuntu machines, that are friendly to new programmers?

If you want to teach someone a command line editor (that's an if, but at some point it will be useful - at the very least as a backup), then nano or pico (pico is often - maybe always - a symlink to nano) is a good idea.

It would be unpleasant to edit in nano/pico full time (no syntax highlighting or indentation help, etc.), but if you have to do something through ssh and emacs or vim are still too much, they get the job done. What makes them new-user-friendly is that they keep a "menu" of basic commands visible at the bottom of the screen. So you can always see how to save, quit, etc.

For GUI editors, Gedit and Kate were pretty popular for (K)ubuntu and other Debian derivatives.

I agree with learning or at least being a bit familiar with nano. It's probably the best way to edit a small one-off file via SSH.

Imagine you want to quickly change a directory path in httpd.conf, instead of downloading the file, editing and then uploading it via FTP - just nano that sumbitch and you're done.

I learn how to use it in about 30 minutes. That's really all it takes to get the basics down.

I would disagree that that's the easiest way.

C-x C-f /ssh:user@host:/path/to/httpd.conf

... and I have it open in my local emacs, with my own settings, with colour and indenting, and no lag when I'm editing. (this is called tramp mode)

And if I then typed M-x eshell, I'd have a shell at the directory where I opened that file, and the nano users would start shouting 'burn the witch!'.

Other editors also support remote editing over ssh - no need to download/upload, the editor takes care of that for you. Working this way, I don't even have to trust that the remote server has nano or emacs or whatever - which it often doesn't.

I'll second that recommendation for nano as a CLI text editor - it does have syntax highlighting, and it's available by default on most relatively modern Linux distros. (But, yeah, for new programming students, Geany is a great choice, as is plain ol' gedit.)
Something like Sublime Text 2 is a good compromise - the best of both worlds.

Some power behind it, not unsimilar to Vim/Emacs. Some beauty behind it, not unsimilar to other commercial text editors / IDEs.

The truth is the editor you use doesn't matter. People who know Vim swear up and down on it, but that's because they are good with it, they have been using it for over 5 years - of course they're proficient with the editor.

Other people are fast with editors like Sublime Text 2.

Others with an IDE like Visual Studio or RADRails.

Tools don't matter, your workflow does. Personally, I'd teach those kids how to use Sublime Text 2.

You can use an Emacs config that'll set CUA bindings that people are more familiar with. (C-o to open files, C-s for saving, C-n for a new window, etc.) I've got a config you can start from.

Who the hell uses default Emacs key bindings anyway? ;-)

Sublime text or Spyder. Others have talked about ST, I'll talk about Spyder. Spyder is a little bit bigger of a hog, but it has autocompletion for functions which is incredibly handy for discovering what can be done, and it helps you pick out the differences between objects (oh, a list and a string have these similar operations to them, cool!).

It has a built in console, which is great to keep focused on single screen. Instead of resizing and shuffling windows, just keep it all in one display. Press F5 to run your code. Fire up a console and try something out (with autocompletion in the console too).

It also has built in documentation, an object explorer, and some other cool features that are escaping me. It hasn't always treated me nicely (sometimes it forgets to reload my code, or it goes out of style (literally, it loses styles sometimes)), but overall it's a good spearhead for getting up to speed quickly with Python.

Spyder - http://code.google.com/p/spyderlib/

I've been coding since I was 12 (I'm now 30), and it's what I do day-in and day-out. I consider myself to be a pretty solid programmer (Ruby being my primary language for the past 3+ years), and I prefer IDEs like TextMate and RubyMine. IDEs like VIM have too steep of a learning curve when you're trying to just get some work done, and I can do anything (at least anything that I've ever needed to do) with my IDE of choice than I can do with vim.
Would you please clarify if you have learned vim or not?
That's a trick question. You never learn vim. You just suck less at it as time goes by.
No way of not sounding pedantic but neither TextMate nor Vim are IDEs.
Touché, you're technically correct. (The best kind of correct.)
Learning emacs or vim is worth it if only just so you can use it in a tmux/screen session.
Agreed. And, not to start the great text editor holy war, but some variant of vi will be pre-installed on almost any *NIX system (although it's been replaced by nano in a lot of newer Linux distros)
It might just be me, but personally I don't understand what is so bad about plain old Notepad. Everythng I've ever coded (except when at work where I'm forced to use others) has been done on Notepad (or, if I'm feeling in the mood to have some colours on the screen, Notepad++) and I've never had any issues.

Why spend so long worrying about your IDE of choice when they are all effectively glorified text editors?

edit: I'm glad that my comment provoked such a fantastic discussion

There's nothing wrong with using notepad, but you can be significantly more productive with other editors
Really? You honestly believe that?

Will it make me type faster and think faster? I spent 6 months working in a doctors office were I had to type every word spoken for 7 hours a day, the block here is not my efficiency, it is in fact my intelligence.

"Will it make me type faster and think faster?"

No, but syntax highlighting greatly enhances code readability and your brains ability to recognize what types of objects or properties or functions are being represented in code. Associating the color blue with a variable declaration, for example, is just there as a visual cue or shortcut for your brain.

I understand your point that it can be done perfectly fine with notepad, but let's not pretend that these visual cues don't give your brain a jump-start.

Oh, I agree, the syntax highlighting does help when I'm reading back through it, but in the act of actually coding I find it a distraction, I prefer not to look while I code and the colours draw my eyes.
Transcribing audio is not programming. Programming has very exacting syntax. Anything that helps (color coding, syntax highlighting, etc) speeds things up. Have you ever tried to write Java without an ide? There's no possible world in which using Notepad is going to be superior to just about anything else.
I have in fact tried and succeeded in writing Java without an IDE, but in all honesty, I believe your using it as an example says more about the overly verbose nature of the language than the tool of choice.
I feel the same way. Most of my time is spent thinking about how I'm going to do something or how I can make it better, I just can't imagine these tools significantly improving my productivity. I use Notepad++ for most things.
It's nice to know I'm not alone here, I was beginning to feel like a duck out of water seeing the other (but also, equally valid) responses.
Typing and thinking faster is pretty much the rationale for every single feature in a text editor, so I'd say the burden is on you to explain why you don't believe it. For typing faster, you can get around the text quickly, do autocomplete, automate repetitive things, etc. For thinking faster, you can more quickly look around a project and get information, you can access documentation and metadata easier, and you can more easily create quick prototypes for testing ideas.
I perfectly agree with you that using a quality IDE allows you to achieve all of those things and I don't argue that features such as autocomplete (and I believe you touched on macros) can be extremely useful.

But I still pose the question, why is it worth the time to learn what is considered a complicated IDE (if it needs to be taught)? Would the time not be spent better, say, being genuinely productive, rather than merely preparing for future productivity?

We live in the here and now, my boss wants to hear that my project will be done on time, not that it will be a week late because I need to learn the more fickle aspects of an IDE he didn't sanction before I can finish it.

I disagree that needing to learn something is counter productive. They are simply extra capabilities, and you don't need to use them if you don't want to. I've been using visual studio for a few years now an I still out of the blue find an extra capability that makes me have to hit less buttons, or not having to touch the mouse.

Little things like jumping to a function with pressing a button, or finding all things that are referencing a function\class\etc are extremely useful, but certainly not necessary. Then things like intellisense are a godsend.

That being said, a lot of my time is spent out of visual studio, but with Sublime Text which add's a lot of things that simply make me have to type less, and focus more on the actual task at hand.

I don't honestly have a response to this, thus far my comments have been based upon opinion, do you have a link to Sublime Text? I feel the only way to truly decide will be for me to install it and try it myself for a week and then attempt to decide fairly which I prefer.
What do/did you program?

why is it worth the time to learn what is considered a complicated IDE (if it needs to be taught)? Would the time not be spent better, say, being genuinely productive

Why delegate work when that takes time you could spend doing the work yourself? Because you can't do everything. At some point delegating starts to pay a return on the effort.

The goal is for You + Computer to create a system which is greater than the sum of its parts. For you to use the computer as an external brain.

If it's just you and notepad-as-typewriter, you're doing all the work.

If you're going to be programming long enough, saving yourself a few minutes a day by mastering your tools is a real and genuine benefit. When you intend on continuing a career in programming, you're already committed to investing time into deeply learning novel things as you need them to keep up with work -- a new language, a new library, a new system, a new subfield of study -- so it's not as if your work is nothing but trying to complete your current project, as fast as possible.

You shouldn't spend a week learning about an IDE feature in the middle of your project, but you should eventually spend ten minutes to learn to write a macro instead of making the same change seventy times, and maybe you should spend an hour and a half wiring your editor up to your favorite static analyzers and compiler so that you can test and debug your code quickly over the next month.

Well… The discussion is about programming, not dictation.

Vim is very well suited to programming because we spend a significantly longer time thinking about, navigating and modifying code than actually writing it.

That's how most people do programming and Vim is ace for all of that thanks to:

* text-objects and motions to fly through your code and edit with laser-like precision in as few keystrokes as possible

* counts to perform repetitive actions in a flash

* ranges for when you want to act on a specific part of the file

* incsearch

* :global

* macros

* :s/foo/bar

* etc.

When it comes to actually write new code, Vim doesn't help much. Well… if you don't consider:

* filename completion <C-x><C-f>

* keyword completion <C-n>

* line completion <C-x><C-l>

* <C-r>= to insert the result of an expression

* <C-y> to input the char above the cursor

* etc.

But then again, we are talking about programming, here, and nobody ever pretended that Vim was the answer to every problem. Or even your problem, for that matter.

In a situation like yours, I'd probably use something like Dragon or simply use stenography like my secretary mother did 30 years ago. I'm very much in love of Vim, actually, but I wouldn't recommend it to anybody that is not a somewhat experienced coder. And even then, there's an entire population of programmers who spend their days generating code, fighting against OOP hell and refactoring refactorings. Those people would probably not derive any benefit from using Vim. Just like you. And nobody is trying to sell them Vim. Just like you.

Use the right tool for the job.

It might just be me, but personally I don't understand what is so bad about plain old Rocks. Everything I've ever hammered (except at work where I'm forced to use other) has been done by Rocks (or, if I'm feeling in the mood to have some recessed nails, convex rocks) and I've never had any issues.

Why spend so long worrying about your Hammer of choice when they are all effectively glorified Rocks?

A skilled artist utilizing a rock correctly can do a better job than another person using a hammer.
That isn't an argument for using a rock. Just because Beethoven was capable of composing incredible symphonies while deaf doesn't mean that you should deafen yourself while composing.
But here you reverse the burden of action, if every person was born death, as if the metaphor is applied to reality, then surely, the others go out of their way when they could be composing incredible symphonies all along?
Totally true, but what could that same skilled artist do with a hammer?
What languages do you typically work iwth?
Mostly PHP at work, with anything from pure php to zend or codeigniter (both of which don't have correct syntax highlighting in the IDE we have to use there.)

When I get home it's anything from C++ to Java, but occasionally in my spare time I throw together the occasional Python script (and once, Ruby, when I was working with a program called GameMaker which accepted plugins only as DLLs or imbedded ruby scripts)

Have you considered using an editor like Komodo (auto completion, auto indentation, syntax highlighting of strings and variables within strings) or Notepad++?

You can certainly code in Notepad, and you can write code with "cat > filename" too. Most of us that have had even the slightest exposure to more powerful editors dismiss Notepad as "Not the Right Tool for Programming", in much the same way that a chef will dismiss a butter knife (or a spoon) as not a proper tool for slicing vegetables. Consider that there may be some merit in such an assessment, and that there may be ways in which other editors may serve you better.

If you _seriously_ use Notepad regularly as a programming editor, I urge you to try Notepad++ or Komodo as an alternative for at least a WEEK, and see what you like better about Notepad. This will help you overcome the initial unfamiliarity enough to see the things that they offer which Notepad does not.

In the other editors: - You can open more than one file easily. - They will re-open what you last had open, if you like (I do). - Komodo will recognize nearly every format you might be coding in, and color-code it in a way which helps reduce errors, because you can immediately see when the color coding is different from what you expected. - Some editors will flag syntax errors as you type.

Give it a shot. Try another editor. Nearly any other editor. I personally enjoy using Komodo at home and at work. Sublime Text 2 is beautiful, though its keybinds do not agree with my muscle memory. Notepad++ is free and awesome.

I used to code in Notepad ages ago when I didn't know any better. It was ok, but for some weird reason now and then when I would save a file all of the linebreaks would disappear. I've never found out if that was an issue with notepad or windows or just some random dumb thing i was doing or what but I can't even touch it now.

Notepad++ with its syntax highlighting is awesome.

How do you indent your code? Not having my editor handle the indentation is the first thing I'd miss.
I feel like emacs is being unfairly lumped in with vim as "one of those powerful editors that are a million years old".

The difficulty he is describing here applies to vim/vi only (modal text editing). With emacs the default setup has menus, typing inserts text into the document. You can do file->save. It is newbie friendly because you can learn bits and pieces of the powerful stuff as you go

To be fair, gVim adds relatively the same features, file/save, etc.
I would definitely not call emacs "newbie friendly"
This is only partially true, as Emacs still has very nonstandard default key bindings. I feel that if Emacs developers enabled more standard bindings by default (i.e. cua-mode, C-o for opening files, C-s for saving, etc), Emacs could win _a lot_ of new users, because, well, it wouldn't be much different than gedit in terms of basic usage. Traditional key bindings could be enabled by a single line in ~/.emacs .
Maybe, but it would also cause complete havoc, because the "standard GUI" keybindings conflict with enormous swathes of Emacs standard keybindings (remember, some of them conflict with Emacs key prefixes...), and Emacs has a lot of keybindings. Once you've started to move stuff around, the conflicts cascade, and there's simply no easy way to recover, especially as many keybindings are made in 3rd-party packages, over which there's little control.

Given that there's actually a rather small number of "standard GUI" keybindings, it actually seems much more tractable to simply ask people to relearn those. It simply isn't a huge burden compared to the alternative...

The sort of people who would be completely loathe to relearn the few "standard GUI" bindings will probably use the mouse/menus instead anyway (and I've observed many newbies happily using Emacs without ever touching the keyboard except when entering text!).

Mixed feelings about this.

I think there is another skill, somewhat related to programming, that we need to teach before programming: text slicing and dicing.

The entire point of a programmable powerful editor is to apply text transforms more quickly than you could with click and type. If that's important, then we should teach it first. I personally believe it is important because of the huge productivity multiplier it gives programmers.

Now I'm thinking about Bart Simpson writing the 30+ sentences in the blackboard in one go, by using 30+ input cursors in parallel.
Related: I think perhaps the most valuable aspect of teaching beginners how to use vim/emacs (in a basic sense at least) is that it isn't necessarily just for programming. You can "practice" with just about everything you write, and if you stick with it become even more efficient in all your other work outside of programming. I started writing almost all of my letters and essays in vim because it's so much faster and in one environment that I can modify to my own needs.
What kind of settings do you use when in letter-writing-mode? I feel like vim is fairly useless to me for anything that isn't 80 (or 100) character max line based, which isn't how I write letters at all. If I autowrap then its a giant pain to reflow the text (maybe there's an easy way to do that), and if I don't then simple navigation is a giant pain.
:set tw=80

:set wm=4 (wrap margin)

Or :help gq to see plorkyeran's suggestion.

In your vimrc(it's a single line): " <Leader>W -> Blog mode. Allows for using vim to write long sentences and paragraphs

nnoremap <leader>W :set colorcolumn=0<cr>:set syntax=markdown<cr>:nnoremap j gj<cr>:nnoremap k gk<cr>

They're orthogonal skills though - new programmers have a hard enough time with the concepts of arrays and variables, and won't be productive until they get those straight, no matter how leet their text editor skillz are. I think the OP is right to suggest learning one at a time.
I agree. Text slicing and column-mode editing are the bees' knees. Being able to use it effectively is similar to being able to leverage multiple layers in an image editor: you won't want to go without it when it's the Right Tool.

In Eclipse, control-shift-a will toggle it, and in Komodo you can just use alt-shift to select in a column. (I like Eclipse's mode toggle better, frankly.) It exists in several other editors, of course -- I think Sublime Text 2's demo reel includes it.

You may wish to investigate the early non-screen editors like teco (DEC), ted(MULTICS), or qx (UNIX).