Reasons To Give The Vim Text Editor A Chance | Hacker News Reader

Reasons To Give The Vim Text Editor A Chance

makeuseof.com

41 pointssurfingdino67 comments

Just last week I was about to start learning Vim, but after perusing the shortcut list I decided I could do better, so I rolled my own. Basically it's just a multi-modal keystroke catcher/dispatcher running transparently in the background. The upshot is that most of the commands work transparently in my IDE, in notepad, and even this little textbox I'm typing in right now!

Unfortunately, the original point was to increase my productivity, which I've failed at horribly... because I can't stop playing around with the code!

Open source it and we can all waste time playing with the code!

Definitely. I'm gonna dogfood it a few more weeks and then throw it up on github.

"Basically it's just a multi-modal keystroke catcher/dispatcher running transparently in the background. The upshot is that most of the commands work transparently in my IDE, in notepad, and even this little textbox I'm typing in right now!"

This sounds very interesting.

I've long wanted vim integration with Opera, so I'm not stuck with its relatively primitive editing features when I'm filling out a text input box. Unfortunately, vim does not integrate with other apps very easily.[1] So something along the lines you're working on would be very welcome, even if it is primitive compared to vim.

One thing I hope it can do is have an easy way to activate and deactivate it, so it doesn't interfere with editing in vim itself.

[1] http://www.freehackers.org/VimIntegration

My reasons for being a vim user a lot more practical than those I see on these "top 10 reasons for trying X":

- In the long run, it's faster to learn and use an "efficiency" editor, so I need to learn one of vim, emacs, notepad++, etc. The differences between these are probably negligible for a proficient user.

- Of these, only vim will be installed (or vi, which has a big enough overlap that it won't matter to me) on every system I'm going to need to use.

These are, incidentally, the same reasons I use QWERTY instead of Dvorak.

Dvorak has actually been shown to really be no better than QWERTY - http://reason.com/archives/1996/06/01/typing-errors/3

You're right about that, but Dvorak is much easier on the hands. The average distance travelled by your fingers is greatly reduced. (It looks like Colemak beats both, though: http://colemak.com/Compare.)

I type Colemak 99% of the time, but the 1% I don't, it can be a really frustrating experience. It amazes me that 20 years of typing ability was forgotten almost entirely in a month.

I used to use Dvorak at home and QWERTY at work (as to not annoy my co-workers) and switching between them was a non-issue.

There's a big exception to the "vim will be installed" rule: Windows.

And what windows installation comes with any dev tools by default? You are going to have to install a bunch of stuff anyway. Install Vim.

I've been tooling around with emacs, having plopped down vimpulse and viper on it. I get slime for clojure, the power of elisp for modifications and so on, as well as my preferred editing style, which is modal. It's not for everyone, but it works for me. It helps that my life isn't terribly busy, and I enjoy taking the time to make everything work together. Of course, caps rebinding is a must for either.

It's been fun, either way. Time will tell if it ends up being practical.

When I started learning Lisp, I tried using Emacs with viper and vimpulse.

Although it did make using Emacs less painful, it still required way too much knowledge of Emacs to use effectively and configure than I had time to dedicate to learning it.

Emacs+SLIME+vimpulse+viper might be good enough for someone who already knows Emacs or who hasn't invested a lot of time in learning vim. But for someone fluent in vim, I just don't think huge time investment in learning Emacs well is worth it.

That's completely understandable. I really don't have a huge reason to be doing things this way. I've just been going through The Joy of Clojure and decided to give emacs a spin, and I wanted some similar editing idioms while messing with it.

I've basically been translating the shortcuts and techniques I use in vim into some ugly elisp, bit by bit, assuming they don't work as expected with vimpule/viper. I wouldn't say it's an amazing solution, but mucking through the emacs docs to get things working has been a quick way to get a basic proficiency in how emacs works, and how elisp can be used.

Ultimately I still end up in vim for most of my editing, and I keep tacking things onto emacs as I go, but mostly when I'm just writing some clojure. I wouldn't say it's efficient at all; it's just interesting enough to kill time with because my life isn't very busy and it seems 'nifty'.

I love vim, I use it daily, but always for quick text editing. For real coding I need an IDE (netbeans). I never understood how people can code without debugging, profiling, code exploring. I'll probably get voted down, but, what Vim saves me, I wasted it on debugging. So I don't see any advantage using it as my primary editor.

I never understood how people can code without debugging, profiling, code exploring.

I'm sure many vim users wonder the same thing. They may also wonder how people can develop using tools that are coupled to each other rather than choosing the various development tools as they see fit.

In any event it's not either/or. The times I've needed Netbeans, for example, I use vim for actual code editing and the IDE for assorted handy click-here-to-run things.

Theres also Eclim for Eclipse which will let you have one of a running modes: Headless eclipse, VIM embedded in the editor, or you can just open it externally.

Does the embedded vim use the users' config files? I've gotten quite used to assorted macros and helpers.

I'm a full-time Vim user.

This was my problem when I started with Vim. But then I learned to love GDB and other command-line development tools. At first it seemed a bit archaic to me, a Visual Studio user at the time, but when I got a hang of it, I stopped missing IDE debugging. Now I'm at the point where I feel crippled trying to develop in an IDE (no split windows, to vim-style macros, inefficient use of screen space, constantly have to switch between mouse and keyboard).

For example, GDB can be scripted, so you can repeat debugging sessions, your entire debugging session is printed, so you can always go back and see the history of changed values. It supports pretty-printing STL containers and you can add your own pretty-printers in python.

There are a lot more to these tools than you can discover by poking and trying things like you would with an IDE, they have a steeper learning curve, but I wouldn't dismiss them immediately as a waste of time.

What about project-wide find and replace? I have been looking to switch to vim, but I do this fairly often and don't see anything that compares to what a good ide can do in vim (without bash command madness).

Try bufdo, argdo, windo, and tabdo depending on the subset of files you'd like to modify. E.g., to replace "foo" with "bar" in all open buffers:

  :bufdo %s/foo/bar/g | update

Although I wouldn't knock `bash command madness' for this sort of task. :)

The Unix shell is pretty much designed for advanced text manipulation across files. E.g., to replace all instances of foo with bar in HTML files, recursively:

  $ find . -name '*.html' -exec perl -i -lpe 's/foo/bar/g' {} \;

vim and the shell are not so far apart and complement each other well, so it pays to understand them both.

I agree. I've also found this perl script handy for recursive find/replace: http://www.neilgunton.com/doc/deep

$ deep replace "foo" "bar" "*.html"

Most people that use vim also don't use graphical debuggers. I use the "print" statement.

Spewing print statements all over a piece of code is as bad as any other shotgun debugging technique. The reason breakpoints and watches were invented were to reduce reliance on bad ways of doing things.

What's good about print statements is that they don't require me to do anything more than once. When you run code in a debugger, there is a lot of manual interaction involved. continue, break, see where you are, think about that, poke around, repeat. With print statements, you run your test, analyze the output, and make the changes. It's all automated except for the analysis step, which is all the human should be doing.

If you need breakpoints, watchpoints, and a GUI to click around in, your code is too complicated and unmaintainable, which is probably why you need a debugger in the first place.

Manual interaction? Sorry, but I'm still very skeptical. Pausing in a debugger does not require materially more "manual interaction" than endlessly running your program to spit out some printed statements--it just front-loads the manual interaction so you're doing it sooner and, if you're doing it right, doing less of it. A debugger allows live autopsy, which is far more valuable than this silly print-statement thing--when your print statement does not return as expected, you are not much better off with your print statements than just seeing the broken output of the program.

Couple live autopsy with live edit-and-continue and you've got a recipe for a considerably more effective way of debugging code.

And "your code is too complicated and unmaintainable if you need a debugger" is preposterous on its face if you've ever...oh, I don't know...written a driver? Or any other remotely complex (you're conflating complicated and complex) task with a significant number of interlocking parts? (Hell, one could just as easily say that your code is too complicated and unmaintainable if you're barfing print statements all over the place.)

You "step over" instead of "step into". Now what? You have to start over.

With test cases and print statements, starting over is free. If you need more information, edit the code to give it to you and re-run.

Getting a debugged program back to the desired state is, in my experience, difficult even with an automatic test. Not only does the program state have to be right, but so does the debugger state. Without the debugger, you have half the state to bother with.

I like logging for this, but the concept is basically the same. Being able to switch on debug logging on a running system has saved the day more than once for me.

Thing is, logging and debugging are not in opposition. My current web app is...well, verbose is probably putting it mildly. But when developing locally, if something goes sideways I just say "hey, stop here" and I can introspect the entire kit and kaboodle without even having to re-bounce the debug server (and certainly without stopping it to bung in a bunch of print statements).

I agree somewhat (although I do feel that debuggers are useful) in that IDEs can influence the design of your program by encouraging a debug first development style similar to "programming by coincidence"

Nobody is putting print statements all over the place. At least I don't do. I set it where I want to inspect values. If you want a separate piece of software for that, more power to you, but please don't tell me my nails must be crooked because I use a different hammer than you.

This assumes you know ahead of time exactly what values must be inspected to solve the problem. This is frequently very much not the case, especially if you're ever working on somebody else's code.

So, yes, your nails may be straight, but your chosen (regressive) technique leaves you with no way to know if they're straight and with only the option of pounding harder and harder if the nail doesn't go in the first time. Enjoy!

Of course I know, that's why I read the code for. Understanding the code base is my job. Using print statements to exclude factors which could contribute to the problem is not different from using a debugger to do the same.

If you debug without knowing what you're debugging and just looking for getting it running, it sounds like you're the one doing the shotgun-programming/debugging, separate debugger or not.

I'm not sure what code you write or what it's for, but in the real world, sometimes we deal with buggy, archaic and downright bizarre code that we didn't write, and sometimes we have deadlines.

So, yes. I use a debugger, so that I can spend some time at home too. Because as nice as the office is, it's summertime, and there's beer in my fridge.

Back when I was seventeen and staying up all night writing a video game engine though, I definitely would have been onboard with the whole print debugging idea.

Nice ad hominem, doesn't work though. I'm 30 and have been developing for 14 years now. And yes, it's real world. And it's mostly Perl, so I do know about "buggy, archaic and downright bizarre code." I'm still more productive with print statements than having a separate system poke around in the applications.

But again, I must be wrong because I'm doing it different, right? So the only option can be that I'm too young, don't know what I'm talking about, or just lack experience in general, right? There couldn't be a possible way that someone else uses a different solution that works just as fine for them, right?

Considering that I never said "Don't use a debugger." only that "I don't need a debugger", you guys seem pretty worked up considering that you're claiming you're the more relaxed one.

It's a tool, don't take it personally that I have a different method that works. It doesn't invalidate yours. At least not in my view.

Honest question (as I avoid Perl like the plague) - is there an introspective debugger on par with Visual Studio's in Perl-land?

Because if you're leaning on print statements in absence of appropriate tooling, I can understand that. When the tooling is available, however, I am skeptical of claims as to enhanced productivity or any other positivity coming from it.

There's a way to get a good answer from someone, compare his language of choice to a deadly disease. And then ask if it's as good as some proprietary crapware.

What does visual studio? Show the value of variables in separate windows as the code runs? Yes, the perl debugger can do that. You can also inject code and poke the entire program state.

The perl debugger is a perl function that is called for every line and every subroutine entry. Use that to build whatever tool you want, and good luck finding that in Visual Studio.

"Proprietary crapware." Yeah, that's the sign of a really well-balanced, competent developer.

I never said I have enhanced productivity over using a debugger. I said I have no worse productivity.

There's a debugger, there's a REPL, and in general lots of tools which I use if I see the need (the NYTProf profiler would be one). Using a debugger in this scenario (with an interpreted language) just doesn't give me any enhanced productivity over what I'm doing now.

Someday, you'll get to work in a language that has a good REPL, and you'll never want to go back to printing. :)

I'm sorry, but this is condescending and simply false, even with the smiley face. I use output for inspection in Perl, Scheme, Javascript, and for (what are in my world) good reasons. The print statement usually doesn't influence the running program in any way. That means no matter who wrote the interpreter/compiler, the debugger, or whatnot, the printing won't have much influence on the program. But I've heard "Why is this bug only showing up in the debugger?" more than once in my time.

Someday, you'll want to run your code more than once, and you'll write tests instead of typing them into the REPL.

Print statements aren't meaningful tests, though. Hence the eight hojillion xUnit ports for pretty much every major language.

OK, so say you have some test that creates a foobar object and invokes the method baz, which does some stuff that you care about. The test fails. What do you do? Do you pick apart the implementation of baz in the REPL, or do you add some print statements inside baz?

The second option is easier. You obviously remove them once your understanding (and tweaking) of the code leads to a passing test.

you set a trace point inside baz, investigate with the REPL, and fix your code.

wait.. what? are you scanning stdout with your tests?

The only downside to print statements is forgetting to remove them and having some obnoxious message committed.

A useful trick we've had at previous workplaces which solves this (and related accidental-debug-code-checkin) problems is to put a precommit hook that denies a checkin with a certain string in the text (we used "DNCI" for Do Not Check In)

So you get in the habit of annotating test tweaks & debug prints with:

printf("DNCI x is %d\n", x);

I use gdb as well, but sometimes dumping data directly is all you really need.

This is rarely a problem when using tools like darcs, magit, or git-add --patch.

It is actually possible to run full interactive debuggers inside vim. Personally I think Netbeans is a little easier on the eyes when doing this, but being the nerd I am I had to give it a go once I found out it was possible. Here's screenshot of me doing a debugging session of a PHP file using vim/Xdebug on OSX :-)

http://morganpyne.com/img/hacks/debugging-php-with-vim-and-x...

There are several articles out there on using vim as a fully-fledged IDE and setting up interactive debugging: http://www.koch.ro/blog/index.php?/archives/63-VIM-an-a-PHP-... http://tech.blog.box.net/2007/06/20/how-to-debug-php-with-vi... http://colonelpanic.net/2010/08/debugging-php-in-vim-using-v...

Note that these are for PHP development, but I'm sure some rummaging would uncover suport for whatever langugages you work in.

Most of the time, IDEs get these features by calling CLI programs. It's very easy to call CLI programs from VIM/EMACS, and set up bindings to make it very quick. As for code navigation, plugins let you navigate to functions, explore projects / directories, and intelisense.

On the one hand, when developing for a new platform or language, you spend some extra time tweaking on VIM, rather than being able to use the platform developers Eclipse GUI immediately. On the other hand, I've found that being exposed to the command line tools with all their arguments, you are more able to fix problems and automate tasks.

There is no reason you can't use both. I tend to structure my projects using an IDE but do most of my text editing in vim.

Nothing beats vim for grunting through a pile of code that needs cleaning up. Just set up your IDE and vim to autoload when it detects changes.

My workflow generally goes Edit in vim -> check IDE for syntax errors -> Run/Debug -> repeat.

Well.. apparently people are using "print" still, but fwiw, most professionals I know (including myself) who use vim also use screen, which lets you keep your commandline utils for debugging, etc, a keystroke or two away.

most IDEs these days (intellij, eclipse, visual studio) have pretty kickass vim plugins so you can have your cake and eat it too.

I chose it because I am under the impression that it is more ergonomic than Emacs and mainstream text editing environments. I learnt the basics of Emacs before I learnt vi/m.

Coincidentally, all the points equally apply to Emacs. Well, except the last one, I guess.

Exactly. Emacs doesn't need an elaborate case for its defense; non-modal is more natural/easier-to-learn/BETTER (control-this, control-that) than modal. Not merely my 2 cents -- it's the TRUTH!

Long time vim user here, and I'm considering learning emacs. How do you know it's the truth? And, how did you get started?

I've been using emacs since the 1980s, got started in school because it's the editor one of my early comp. sci. courses used. Tried vi a few times, and I still use it occasionally on systems where emacs is not available (this is one real advantage of vi[m] it tends to be on even the most bare-bones systems), but the separate input and command modes have never really felt natural to me.

I've tried hard to love vim, but as a programmer's editor, for C++, it's just awful.

Now, many of the problems are because C++ is awful (hard to parse, for indenting / formatting), and C++ compilers are awful (20 page error messages).

In particular, I tried half a dozen packages and none could tame C++ template error messages, while xcode, visual studio and cde in eclipse all mastered this years ago. A shame.

My reason for using vi/vim is that it's the lowest common denominator text editor. You'll find it by default on most any Linux or BSD system.

That's my reason too. I use it on Linux, BSD, Mac OS X, and MS Windows. I like TextMate for some tasks better than Vim, but my ratio of time spent in both is still 9:1 (Vim:TextMate).

Reason 8: Vim keystrokes can be incorporated into ex scripts, either alone or in "here" scripts. These commands are already useful, they can do stuff like replace strings in lines that are N lines above or below lines holding another string, and they can be leveraged further via scripting.

For example, a search and replace across files under the working directory:

tgt_string=$1

repl_string=$2

for file_name in $(grep -rl "$tgt_str")

do

ex - $file_name << END_HERE_SCRIPT

%s/$tgt_string/$repl_string/g

END_HERE_SCRIPT

    done

Yes, the indentation of the "here" script is ugly, white space before line texts can bork execution.

Yes, sed or awk can do very similar things, maybe better. My point is, it's nice to get some of these capabilities just by knowing your editor.

(Ed: Sorry about the formatting, if I don't double-space the script it turns into one large text clump.)

When they started pushing Unix on us in 2nd year CS, I hated VIM with a burning passion. After a little while of using it though, I can say my typing efficiency is far, far, higher than it was before, and I can "flow" better since I don't have to interrupt my stream-of-consciousness with a mouse movement. I wouldn't use anything else nowadays.

It's not surprising to see that the logo isn't amongst the list :)

I use a mix of Elvis and Vim as I'm training up on vi-likes, and I'm not sure which I prefer yet. Vim has more-intuitive-to-me stuff like character-by character deleting (ie characters are removed when you delete, not when you leave Insert mode), but elvis has things like pressing = twice to reflow paragraphs.

Vim may win in the end as Elvis is hard to google for...

Vim can reflow too, but I will admit that 'gwap' is a bit unintuitive...

cool, thanks for that!

Reply on news.ycombinator.com