5 ms·

Debugging in Vim

152 points by dstein64 7y ago

arunc 7y ago
GDB text user interface [1] is much easier and productive to use than this albeit it doesn't offer syntax highlighting. [1] https://ftp.gnu.org/old-gnu/Manuals/gdb/html_chapter/gdb_19.html https://ftp.gnu.org/old-gnu/Manuals/gdb/html_chapter/gdb_19....
- archgoon 7y ago
  So, several years ago, I found that using the TUI environment increased the likelihood that gdb would crash (typically also in conjunction with the disassembly view). I do not know if it has become more stable in recent years; has anyone else noticed this more recently, or has it become more stable?
- flukus 7y ago
  The keybindings are for to emacs like for me to consider it easy to use :) It is much more powerful and productive though, reverse debugging and scripting offer far more power than just stepping through code in an IDE. It's probably possible to do that through vim, but at some point your basically using the CLI interface and have to learn GDB anyway.
- dan00 7y ago
  From my experience cgdb (https://cgdb.github.io/ https://cgdb.github.io/) is the more stable TUI interface.
- pksadiq 7y ago
  I find GNU Emacs M-x gdb pretty productive when used with M-x gdb-many-windows. Especially, I like the way I can browse and look deep the local variables (middle-click [or Shift-Enter] on any pointer variables in "local" window, which opens speedbar with its contents), along with other common features.
- wgml 7y ago
  GDB 8.3, just released [1], introduced support for syntax highlighting. [1] https://lists.gnu.org/archive/html/info-gnu/2019-05/msg00007.html https://lists.gnu.org/archive/html/info-gnu/2019-05/msg00007...
- ifoundthetao 7y ago
  With GDB you can use all of the glory that is printf, inside of the termal. This means terminal control codes, that you can use to change colors on the screen for syntax highlighting. peda is an excellent project that uses this to great success: https://github.com/longld/peda https://github.com/longld/peda All of that being said... it's really not very practical. (: But, it CAN be done, and it is done, I'm just glad I'm not the person doing it.
darkpuma 7y ago
Damn, I was hoping this would be about debugging vimscript.
- michaelmrose 7y ago
  Elisp has a pretty good debugger just saying.
  - deleted 7y ago
    [deleted]
- axelf4 7y ago
  IIRC there is a good article on that topic in Vimways 2018.
AlexCoventry 7y ago
Vim only got integrated gdb support last year? Emacs has had that since last century[0], I think. How do you people live like this? :-) [0]: https://github.com/emacs-mirror/emacs/blob/master/etc/NEWS.18#L127 https://github.com/emacs-mirror/emacs/blob/master/etc/NEWS.1...
- intertextuality 7y ago
  I guess it's not a vim article unless someone refers to emacs/another editor for no reason. Thanks for the unsubstantial comment. Regardless of editor X, Y, or Z, this article is about a feature Vim received. I for one find it useful since, well, I use vim.
  - zeveb 7y ago
    > Thanks for the unsubstantial comment. Given that for decades a primary draw for vi was that it was simple, the fact that people keep adding features to it until it's approaching where Emacs was a few decades ago is noteworthy. Noting that Emacs has had a certain feature for decades, and that the feature has been receiving bug fixes and adding still more sub-features is substantial. Given that users of vim no longer seem to care about simplicity, one has to wonder: why stick with vim? Emacs has a far better extension language (elisp is to vimscript as a thermonuclear weapon is to a sharp stick), evil-mode can accurately replicate the vim editing experience, and Emacs has far more features and packages now than does vim. It's a bit like preferring a race car to a van because you want speed, but then deciding you want to haul packages for a living and bolting on a 2-ton flatbed to the back of your race car. You end up wasting fuel and still not carrying as many packages as you could with a good van — and not running as quickly, either.
    - mmcgaha 7y ago
      Having features and having features that serve a groups needs at the right time are different things. The first time I fired up emacs was in 1995 on a pentium 66 with 8 MB of RAM. It made my computer grind to a halt so editing text was not going to happen. When I tried vi, it ran like I expected a text editor to run. So here I am today, my fingers long trained up to use vi, and I find little need to learn emacs. Sure emacs has had useful features for years, but the barrier to entry was just too high, and now it is too late to win over folks like me.
caymanjim 7y ago
This is a good article, but the real major feature that Vim 8 introduced wasn't running a terminal inside Vim (which has been possible in various forms forever), but support for asynchronous processing. The terminal is just one use case for the new async functionality, which is powering all sorts of useful plugins or behavior which used to be blocking.
- westoque 7y ago
  I myself don't see the value of running a terminal in the editor. I see as an added complexity: did the makers of the editor code it the right? Is there any side-effects? Is the ENV correctly loaded? If adding an editor is simply saving you an "alt+tab" then isn't it a lot of effort just to avoid that?
  - cglouch 7y ago
    one nice thing about having the terminal within vim is that you can manipulate the output like any old buffer. So for instance if you want to copy something from the terminal into a script you're editing, you can yank the text from the terminal and paste it into your script, taking advantage of vim's editing features and without needing to move your mouse.
  - caymanjim 7y ago
    That's not how it works. The terminal is running your login shell. All it has to do is launch an arbitrary process and then properly emulate xterm or whatever. Environment is handled identically to any other terminal session. Concern about it being "coded right" is misplaced. The benefit is that you can copy data to/from it like any other Vim buffer. It fits a certain workflow that some people prefer. If you don't consider alt-tabbing out of Vim to another window to be a big deal, it's probably not the workflow you're after, but for people like me who live inside a terminal and won't tab out for anything other than a web browser, it's useful. That said, I normally use another tmux window.
samueloph 7y ago
I would like to see a post like this but for Python. This one is for gdb.
passthejoe 7y ago
Having a terminal in Vim is very convenient.

152 points by dstein64 7y ago

GDB text user interface [1] is much easier and productive to use than this albeit it doesn't offer syntax highlighting. [1] https://ftp.gnu.org/old-gnu/Manuals/gdb/html_chapter/gdb_19.html https://ftp.gnu.org/old-gnu/Manuals/gdb/html_chapter/gdb_19....

archgoon 7y ago
So, several years ago, I found that using the TUI environment increased the likelihood that gdb would crash (typically also in conjunction with the disassembly view). I do not know if it has become more stable in recent years; has anyone else noticed this more recently, or has it become more stable?
flukus 7y ago
The keybindings are for to emacs like for me to consider it easy to use :) It is much more powerful and productive though, reverse debugging and scripting offer far more power than just stepping through code in an IDE. It's probably possible to do that through vim, but at some point your basically using the CLI interface and have to learn GDB anyway.
dan00 7y ago
From my experience cgdb (https://cgdb.github.io/ https://cgdb.github.io/) is the more stable TUI interface.
pksadiq 7y ago
I find GNU Emacs M-x gdb pretty productive when used with M-x gdb-many-windows. Especially, I like the way I can browse and look deep the local variables (middle-click [or Shift-Enter] on any pointer variables in "local" window, which opens speedbar with its contents), along with other common features.
wgml 7y ago
GDB 8.3, just released [1], introduced support for syntax highlighting. [1] https://lists.gnu.org/archive/html/info-gnu/2019-05/msg00007.html https://lists.gnu.org/archive/html/info-gnu/2019-05/msg00007...
ifoundthetao 7y ago
With GDB you can use all of the glory that is printf, inside of the termal. This means terminal control codes, that you can use to change colors on the screen for syntax highlighting. peda is an excellent project that uses this to great success: https://github.com/longld/peda https://github.com/longld/peda All of that being said... it's really not very practical. (: But, it CAN be done, and it is done, I'm just glad I'm not the person doing it.

darkpuma 7y ago

Damn, I was hoping this would be about debugging vimscript.

michaelmrose 7y ago
Elisp has a pretty good debugger just saying.
- deleted 7y ago
  [deleted]
axelf4 7y ago
IIRC there is a good article on that topic in Vimways 2018.

AlexCoventry 7y ago

Vim only got integrated gdb support last year? Emacs has had that since last century[0], I think. How do you people live like this? :-) [0]: https://github.com/emacs-mirror/emacs/blob/master/etc/NEWS.18#L127 https://github.com/emacs-mirror/emacs/blob/master/etc/NEWS.1...

intertextuality 7y ago
I guess it's not a vim article unless someone refers to emacs/another editor for no reason. Thanks for the unsubstantial comment. Regardless of editor X, Y, or Z, this article is about a feature Vim received. I for one find it useful since, well, I use vim.
- zeveb 7y ago
  > Thanks for the unsubstantial comment. Given that for decades a primary draw for vi was that it was simple, the fact that people keep adding features to it until it's approaching where Emacs was a few decades ago is noteworthy. Noting that Emacs has had a certain feature for decades, and that the feature has been receiving bug fixes and adding still more sub-features is substantial. Given that users of vim no longer seem to care about simplicity, one has to wonder: why stick with vim? Emacs has a far better extension language (elisp is to vimscript as a thermonuclear weapon is to a sharp stick), evil-mode can accurately replicate the vim editing experience, and Emacs has far more features and packages now than does vim. It's a bit like preferring a race car to a van because you want speed, but then deciding you want to haul packages for a living and bolting on a 2-ton flatbed to the back of your race car. You end up wasting fuel and still not carrying as many packages as you could with a good van — and not running as quickly, either.
  - mmcgaha 7y ago
    Having features and having features that serve a groups needs at the right time are different things. The first time I fired up emacs was in 1995 on a pentium 66 with 8 MB of RAM. It made my computer grind to a halt so editing text was not going to happen. When I tried vi, it ran like I expected a text editor to run. So here I am today, my fingers long trained up to use vi, and I find little need to learn emacs. Sure emacs has had useful features for years, but the barrier to entry was just too high, and now it is too late to win over folks like me.

caymanjim 7y ago

This is a good article, but the real major feature that Vim 8 introduced wasn't running a terminal inside Vim (which has been possible in various forms forever), but support for asynchronous processing. The terminal is just one use case for the new async functionality, which is powering all sorts of useful plugins or behavior which used to be blocking.

westoque 7y ago
I myself don't see the value of running a terminal in the editor. I see as an added complexity: did the makers of the editor code it the right? Is there any side-effects? Is the ENV correctly loaded? If adding an editor is simply saving you an "alt+tab" then isn't it a lot of effort just to avoid that?
- cglouch 7y ago
  one nice thing about having the terminal within vim is that you can manipulate the output like any old buffer. So for instance if you want to copy something from the terminal into a script you're editing, you can yank the text from the terminal and paste it into your script, taking advantage of vim's editing features and without needing to move your mouse.
- caymanjim 7y ago
  That's not how it works. The terminal is running your login shell. All it has to do is launch an arbitrary process and then properly emulate xterm or whatever. Environment is handled identically to any other terminal session. Concern about it being "coded right" is misplaced. The benefit is that you can copy data to/from it like any other Vim buffer. It fits a certain workflow that some people prefer. If you don't consider alt-tabbing out of Vim to another window to be a big deal, it's probably not the workflow you're after, but for people like me who live inside a terminal and won't tab out for anything other than a web browser, it's useful. That said, I normally use another tmux window.

samueloph 7y ago

I would like to see a post like this but for Python. This one is for gdb.

passthejoe 7y ago

Having a terminal in Vim is very convenient.