5 ms·

I am disappointed to see that Vintage mode hasn't really been touched at all for this edition. It's what is holding myself (and likely others) back from switchi

by tomlu 14y ago

I am disappointed to see that Vintage mode hasn't really been touched at all for this edition. It's what is holding myself (and likely others) back from switching away from Vim. Unfortunately, development of Vintage mode seems to have stopped (the repository hasn't changed for about six months).

princemaple 14y ago
he will go back to it soon, I think
- tomlu 14y ago
  That's great news - do you have a source (maybe a forum post) for that?
  - princemaple 14y ago
    not really, but the man spent all his time on S3 development, I think it's the reason that we haven't seen any progress in vintage mode. With S3 beta released, I guess he doesn't need to stick to it every second any more.
mikevm 14y ago
As someone who only used IDE debuggers all his (short) programming career, I was wondering, how do you debug without a visual debugger? 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)?
- pretoriusB 14y ago
  >As someone who only used IDE debuggers all his (short) programming career, I was wondering, how do you debug without a visual debugger? 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.
  - stevvooe 14y ago
    Even then, Gdb kills many competitors on flexibility alone.
  - kamaal 14y ago
    This is something I have always wondered about. 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 https://metacpan.org/module/Devel::NYTProf
    - marcusf 14y ago
      Depends on your use case. If you're trying to find an issue in Java code running on an app server somewhere where you're not allowed to update code (say, if you work in B2B and it's a customer site), being able to remote debug does wonders.
  - venomsnake 14y ago
    Hmm ... a few cases i could think of. Memory stomp bugs. Race conditions. And some Entrprise OO problems - inspecting 260 layer stacktrace and exploring very complicated structures.
  - dagw 14y ago
    Debuggers are handy for the last 1% of bugs. And anyway there is nothing about debuggers that precludes logical thinking or requires "blindly" placing breakpoints.
  - veidr 14y ago
    Adding printf statements implies recompiling or rerunning code. A good debugger lets you set breakpoints against your app while it runs, and have the breakpoint log a message instead. So even if you just want to log messages at certain spots, a good debugger works better (to say nothing of following program execution through long sequences of source code files, which is even handier when the source code is some open source component that you didn't write). 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.
- tomlu 14y ago
  I use Vim/Sublime for rote text editing and scripting languages. For most statically typed languages (C, C++, C#, Java, Objective-C and so on) I tend to use an IDE with a Vim emulator. 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.
- jahewson 14y ago
  I found that I wrote much better code once I ditched the IDE debugger, and stopped writing enterprise code... Perhaps the latter outweighs the former in terms of impact. 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).
- Shorel 14y ago
  You printf/echo/out the hell of it.
- lttlrck 14y ago
  When I moved from Windows to Linux development I was concerned how that would affect me. Turns out not so much, I just don't debug as much on Linux :) IDE debuggers make it far too easy to press F5 and see what happens, make a change, press F5 etc without really thinking about what's happening. Iterative coding gone bad. The only time I use GDB is for the occasional segfault that I can't figure out from back-stepping a few revisions, and it always nails it (which is more than can be said for MSVC)
- johncoltrane 14y ago
  Using Vim/Emacs doesn't necessarily means ditching visual debuggers.
dtf 14y ago
What's noticeably missing from Vintage for you? 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)
- tomlu 14y ago
  While a couple of things are missing, mostly it's that things don't work properly. 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 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.
  - phlyingpenguin 14y ago
    While I agree that vintage lacks some refinement, the source for the plugin is sitting in your sublime directory and is fairly easy to hack on. Things like the one-off cursors are fairly easy to fix. I'm not sure what you mean about switching files; I don't notice that particular problem. Do you have '"vintage_start_in_command_mode": true' set in your config? 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.
    - tomlu 14y ago
      The code is quite nice indeed, and oh so small for a vim emulator - I've contributed a significant chunk to XVim which is positively massive in comparison, so I have some frame of reference. 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.

by tomlu 14y ago

princemaple 14y ago

he will go back to it soon, I think

tomlu 14y ago
That's great news - do you have a source (maybe a forum post) for that?
- princemaple 14y ago
  not really, but the man spent all his time on S3 development, I think it's the reason that we haven't seen any progress in vintage mode. With S3 beta released, I guess he doesn't need to stick to it every second any more.

mikevm 14y ago

As someone who only used IDE debuggers all his (short) programming career, I was wondering, how do you debug without a visual debugger? 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)?

pretoriusB 14y ago
>As someone who only used IDE debuggers all his (short) programming career, I was wondering, how do you debug without a visual debugger? 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.
- stevvooe 14y ago
  Even then, Gdb kills many competitors on flexibility alone.
- kamaal 14y ago
  This is something I have always wondered about. 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 https://metacpan.org/module/Devel::NYTProf
  - marcusf 14y ago
    Depends on your use case. If you're trying to find an issue in Java code running on an app server somewhere where you're not allowed to update code (say, if you work in B2B and it's a customer site), being able to remote debug does wonders.
- venomsnake 14y ago
  Hmm ... a few cases i could think of. Memory stomp bugs. Race conditions. And some Entrprise OO problems - inspecting 260 layer stacktrace and exploring very complicated structures.
- dagw 14y ago
  Debuggers are handy for the last 1% of bugs. And anyway there is nothing about debuggers that precludes logical thinking or requires "blindly" placing breakpoints.
- veidr 14y ago
  Adding printf statements implies recompiling or rerunning code. A good debugger lets you set breakpoints against your app while it runs, and have the breakpoint log a message instead. So even if you just want to log messages at certain spots, a good debugger works better (to say nothing of following program execution through long sequences of source code files, which is even handier when the source code is some open source component that you didn't write). 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.
tomlu 14y ago
I use Vim/Sublime for rote text editing and scripting languages. For most statically typed languages (C, C++, C#, Java, Objective-C and so on) I tend to use an IDE with a Vim emulator. 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.
jahewson 14y ago
I found that I wrote much better code once I ditched the IDE debugger, and stopped writing enterprise code... Perhaps the latter outweighs the former in terms of impact. 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).
Shorel 14y ago
You printf/echo/out the hell of it.
lttlrck 14y ago
When I moved from Windows to Linux development I was concerned how that would affect me. Turns out not so much, I just don't debug as much on Linux :) IDE debuggers make it far too easy to press F5 and see what happens, make a change, press F5 etc without really thinking about what's happening. Iterative coding gone bad. The only time I use GDB is for the occasional segfault that I can't figure out from back-stepping a few revisions, and it always nails it (which is more than can be said for MSVC)
johncoltrane 14y ago
Using Vim/Emacs doesn't necessarily means ditching visual debuggers.

dtf 14y ago

What's noticeably missing from Vintage for you? 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)

tomlu 14y ago
While a couple of things are missing, mostly it's that things don't work properly. 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 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.
- phlyingpenguin 14y ago
  While I agree that vintage lacks some refinement, the source for the plugin is sitting in your sublime directory and is fairly easy to hack on. Things like the one-off cursors are fairly easy to fix. I'm not sure what you mean about switching files; I don't notice that particular problem. Do you have '"vintage_start_in_command_mode": true' set in your config? 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.
  - tomlu 14y ago
    The code is quite nice indeed, and oh so small for a vim emulator - I've contributed a significant chunk to XVim which is positively massive in comparison, so I have some frame of reference. 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.