I've seen how GDB works, and debugging this way seems much less productive. You don't see your whole source code, and you don't constantly see the values of watched or local variables, etc... Is there a different debugger you use for this task when developing using only a text editor (vim/emacs/sublime)?
I'd ask the reverse of you. Why do you spend time in a debugger at all? For 99% of the bugs logical thinking and a few printfs work faster and better ran blindly running around setting breakpoints and examining values.
Though learning how to use the debugger is a good skill to learn, these days I don't know anyone around me who has ever used a debugger, or even finds a use for it. I think the best tools of our age are really REPL's, which allows you to test out your guesses/hypothesis in the form of snippets.
Personally I have probably used a debugger 5-6 times in my whole programming career, these days I hardly find a use for it.
On the other hand, I find tools like these very useful: https://metacpan.org/module/Devel::NYTProf
Memory stomp bugs. Race conditions.
And some Entrprise OO problems - inspecting 260 layer stacktrace and exploring very complicated structures.
I agree that printf works better than "blindly running around setting breakpoints", but so does pounding a 12-pack of beer and then hitting yourself in the face with a mallet until the solution comes to you.
On the other hand, learning to use a modern, advanced debugger and then applying that skill along with some of that logical thinking can be extremely effective in finding the cause of bugs as quickly as possible.
For languages like Objective-C or Java, I think the 'real men don't need a debugger bro' attitude is nuts. It is different for a lot of newer and/or more dynamic programming languages, which simply don't have debuggers anywhere close to as powerful as those of IntelliJ or Xcode/lldb.
Also I hate writing prints over and over. Sometimes it is imply faster to put a breakpoint, look at the value and then pop it away. As opposed to manually writing the print, then check, and then removing it.
Thats just my opinion though.
Once you learn how to use a debugger properly it is infinitely better than printfs.
I've been programming professionally for nearly 20 years, in languages ranging from Perl to C/C++ to Javascript, and the only times I've used GDB in the last 15 years have been when C/C++ code is segfaulting and I want a stack trace. The rest of the time I use print/printf statements. I've built some pretty successful software this way, some of which you've probably heard of or used.
On the other hand if I were coding exclusively in C/C++, or Java, or using an IDE for my work, I might use a debugger more.
I'm getting up there too. And I know lots of older programmers with very bad habits. Many who have also working on household names. Age+popularity != skill/quality.
Doing that in anything but interpreted and micro applications seems like a massive waste of time and effort(both placing the printfs, recompiling, removing them recompiling.
We've all done it. It doesn't mean its a good way to do it.
And like I said above it can introduce bugs into your code doing so. I remember one case where a printf for debugging changed the memory in such a way as to make an uninitialized variable work. After testing when the printfs were removed the application would stop working.
Introducing code into your code base with the intention of removing it later when there is an easy way to not do so is asking for trouble.
But honestly, visual debugging is nice and all but I don't know if the debugger is really the biggest loss of not using an IDE - for me it's more the code completion, navigation and refactoring support I'm after. You can get most of that going pretty well with Vim but it's a bit of a hassle.
Firing up GDB for those rare segfaults which I don't immediately know the cause of (the last 2 lines I wrote, usually) gives me a stack trace very quickly, and lets me dump the values of the variables in that frame. I rarely need more. That wasn't the case back in my enterprise days.
GDB is very powerful, check out its integration with emacs for example (not something I've used).
I'm also Vim user who has considered jumping to Sublime several times, but never quite managed to achieve escape velocity. (Though I hadn't realised until now that the Vintage package is an open repository)
Some random things off the top of my head:
* No block cursor (the block cursor plugin doesn't really work)
* When you switch between files, it keeps jumping back to insert mode, but you don't immediately notice (especially since there is no block cursor). There's a setting, but I've never been able to make it work.
* Autocomplete and the dot command don't work together
* Macros are flakey
* Visual mode and the dot command don't work well together
Otherwise, here's the issue page: https://github.com/sublimehq/Vintage/issues?state=open
About 25% of those issues annoy me personally. There are a lot of commands that leave the cursor one off, which messes with my muscle memory.
As far as a vim-style editing plugin goes, vintage has by far been the best I've encountered. It's one of the few where it's fairly straightforward to add in the hacky things I've done to vim and still get a similar experience.
The problem is that if you want all the fixes you pretty much have to compile a version with all the pull requests yourself as they don't get merged into mainline in a timely fashion. I would personally be much more keen to fix these things if I knew that my efforts along with everyone else's were expediently dealt with.
I do have vintage_start_in_command_mode set, but that apparently only works on startup (I read somewhere on the forums that it's a per-file setting, whatever that means).
Vintage is pretty good, but I don't agree that it is top shelf - ViEmu and jVi are both better Vim emulators IMO, and Vrapper and XVim are better in at least some regards.
* Set `"vintage_start_in_command_mode": false` in the vintage preferences.
* You can remove the autocomplete on '.', just look through whatever plugins settings or bindings.
Also, make sure you get the plugin VintageEx.