21–30 of 68 posts
Earlier quoted context omitted.
Most people that use vim also don't use graphical debuggers. I use the "print" statement.
The only downside to print statements is forgetting to remove them and having some obnoxious message committed.
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!
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.
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.
Earlier quoted context omitted.
Most people that use vim also don't use graphical debuggers. I use the "print" statement.
The only downside to print statements is forgetting to remove them and having some obnoxious message committed.
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.
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 inc…
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) o…
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'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 spa…
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
wq
END_HERE_SCRIPT
done
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.)
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) o…
Dvorak has actually been shown to really be no better than QWERTY - http://reason.com/archives/1996/06/01/typing-errors/3
Earlier quoted context omitted.
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 doi…