Debugging in Vim(dannyadam.com)
dannyadam.com
Debugging in Vim
https://www.dannyadam.com/blog/2019/05/debugging-in-vim/
39 comments
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.
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?
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.
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.
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.
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....
[1] https://ftp.gnu.org/old-gnu/Manuals/gdb/html_chapter/gdb_19....
GDB 8.3, just released [1], introduced support for syntax highlighting.
[1] https://lists.gnu.org/archive/html/info-gnu/2019-05/msg00007...
[1] https://lists.gnu.org/archive/html/info-gnu/2019-05/msg00007...
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.
From my experience cgdb (https://cgdb.github.io/) is the more stable TUI interface.
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
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.
peda is an excellent project that uses this to great success: 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.
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.
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.
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?
I would like to see a post like this but for Python.
This one is for gdb.
Damn, I was hoping this would be about debugging vimscript.
IIRC there is a good article on that topic in Vimways 2018.
Having a terminal in Vim is very convenient.
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.1...
[0]: https://github.com/emacs-mirror/emacs/blob/master/etc/NEWS.1...
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.
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.
> 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.
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.
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.
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.
But why is it to late? Evil mode works perfectly. I think you would find the transition quite easy.
It works fine as a vim emulation layer, but as a full replacement for vim it does no better than other vim emulations, like IdeaVim. For example, in vim I can hit : to open command line mode followed by ctrl + f to open a mini buffer for ex commands that can be manipulated like any other vim buffer. I use this feature all the time in vim and it isn't available in any of the vim emulation software I've tried. Now, I'm sure there are plenty of ways to accomplish the same goal in emacs, not disputing that. But the idea that evil mode can simply replace vim and all of its built in functionality? Just not true, at least not currently.
Isn't that the same as q: (you know, such as there is q: , q/ and q?)? In which case, evil implements this as "evil-command-window-ex", which I'm sure you could bind to ctrl + f too (perhaps that should be filed as an issue with evil).
But I'm equally sure that if you made a habit of using e.g. spacemacs, you probably would not need to use it all the time either. But I guess I don't know your workflow. Why do you even use that buffer? I curse every time I accidentally open it.
But I'm equally sure that if you made a habit of using e.g. spacemacs, you probably would not need to use it all the time either. But I guess I don't know your workflow. Why do you even use that buffer? I curse every time I accidentally open it.
I use it for the same reason I use bash history--to view, edit, and reuse ex commands. I'm not surprised that there is a way to customize evil to get to something similar, but my point was that it doesn't work out of the box the way vim does. I've no doubt that it could be implemented, and could file an issue as you suggest, but as someone who uses vim as my daily driver all I can say is every time I fire up evil I run into something like that which immediately turns me off. I guess I just don't have enough appetite for customizing my editor to take up emacs. Just noticed that :h doesn't open the vim help (of course, why should it, this is emacs), but there again, something I use several times a day. I could go on. A big reason I haven't tried harder is that there is no easy path to converting an existing .vimrc to elisp, and over the years I've spent enough time configuring vim to work just the way I want.
Evil can function in the minibuffer too which is somewhat similar. Regardless, the idea that Evil is no better than IdeaVim is kind of ridiculous.
If Evil mode or Spacemacs worked perfectly I'd have switched a long time ago. But based on my experience with it I'd say it would take me months of practice and configuration just to get the same experience. And for what? Just so I can do the same things in just one program instead of two(Vim + terminal)? Not worth it for me.
Besides, as long as hitting the Escape key feels like sending messages in morse code I don't think I'll ever get used to it.
Besides, as long as hitting the Escape key feels like sending messages in morse code I don't think I'll ever get used to it.
Maybe it’s not worth it, and I get that (but learning is fun and makes you smarter!). But Emacs can do much more than vim+Terminal. Debugging, git integration, psychiatrists, pong, Tetris, an awesome calculator that can do integrals and derivatives, etc etc. Also web browsing (you can embed WebKit inside), a full blown window manager (you can embed X apps in it), org-mode (which is amazing), in-line images, equations, flash cards, music player, movie editor, file manager, and much much more.
Emacs is the greatest application I’ve ever used, bar none. I’ve tried vim, and it doesn’t even come close.
Emacs is the greatest application I’ve ever used, bar none. I’ve tried vim, and it doesn’t even come close.
I'm curious if you really think Vim or the terminal can't do any of these things, because it doesn't take long to find replacements for almost all of them(e.g. it's no problem to get image previews with ranger running in Vim). Except the ones that only exist because it's possible and not because it makes sense. Why should I care that a text editor can run a web browser or a music player? Does it bring any additional value except an opportunity for bragging?
Trying to adapt Emacs for me coming from Vim feels like recreating Alpine Linux by modifying an Ubuntu installation: it's pointless, cumbersome and feels insane.
Trying to adapt Emacs for me coming from Vim feels like recreating Alpine Linux by modifying an Ubuntu installation: it's pointless, cumbersome and feels insane.
Saying that emacs is more powerful than terminal is annoying and stupid argument. You can have everything you just listed without any hassle, so why are you trying to impose emacs on others in the flame-war way?
Aside from org mode, I can do the same things with different applications. I don't want one big application that does everything. In any case, I don't extol the virtues of vim in emacs-related posts.
I know you are joking but for me vim was never meant to replace the command line. For me the terminal is the IDE. Vim is the editor, gdb is the debugger, grep is for text searching, etc.
The desire to include more and more in vim mirrors what people have done with emacs but I personally have no use for making vim anything other than a very fast and efficient text editor.
The desire to include more and more in vim mirrors what people have done with emacs but I personally have no use for making vim anything other than a very fast and efficient text editor.
I wouldn't dream of speaking for every vim user, but from casual observation it seems to me that `vim`ers tend to shed plugins as they get more experienced, instead of using more and more of them. So I believe your experience is quite typical.
> tend to shed plugins
There’s a practical side to that - the biggest benefit of vi(m) is that it’s _always_ there, no matter where you’re shelled in to. However, their vi doesn’t have your plugins. So if you get used to using plain-vanilla vi, you won’t be lost when you sit down at (or ssh into) somebody else’s computer.
There’s a practical side to that - the biggest benefit of vi(m) is that it’s _always_ there, no matter where you’re shelled in to. However, their vi doesn’t have your plugins. So if you get used to using plain-vanilla vi, you won’t be lost when you sit down at (or ssh into) somebody else’s computer.
>> down at (or ssh into) somebody else’s computer.
Why would you develop software over SSH is seriously beyond me.
Eg are you actually SSHing into your running docker containers to edit code? The only language that allows for it is PHP - because any other language is either compiled or needs modules to be reloaded.
Are you viewing large datasets in csv files through vim? - This can’t possibly work as vim requires them loaded into memory.
Are you editing config files on your servers using vim? - Do you not use automation to set everytting up on the servers?
Why would you develop software over SSH is seriously beyond me.
Eg are you actually SSHing into your running docker containers to edit code? The only language that allows for it is PHP - because any other language is either compiled or needs modules to be reloaded.
Are you viewing large datasets in csv files through vim? - This can’t possibly work as vim requires them loaded into memory.
Are you editing config files on your servers using vim? - Do you not use automation to set everytting up on the servers?
> SSHing into your running docker containers to edit code
no, not primarily
A few use cases:
1) I'm on a bastion host, and I need to knock up a script to run there
2) I'm working at home, and I don't want turn on the VPN, I SSH into my workstation and develop as if I was on the workstation
3) I need to change a conf/script/other because something is wrong, and the edit->commit->change config run-> test cycle is more than 2 seconds.
4) I'm in a container, debugging something and I want to edit a file (mostly python here so no need to compile) docker build-> run -> retry is painfully slow, and leaves loads of mess.
5) I'm working on a headless box somewhere or other.
6) I'm debugging on someone else's workstation
I only really work with vim in a terminal, so doing it over SSH isn't actually all that noticeable. It does gets to be a problem when the latency is > 200ms
no, not primarily
A few use cases:
1) I'm on a bastion host, and I need to knock up a script to run there
2) I'm working at home, and I don't want turn on the VPN, I SSH into my workstation and develop as if I was on the workstation
3) I need to change a conf/script/other because something is wrong, and the edit->commit->change config run-> test cycle is more than 2 seconds.
4) I'm in a container, debugging something and I want to edit a file (mostly python here so no need to compile) docker build-> run -> retry is painfully slow, and leaves loads of mess.
5) I'm working on a headless box somewhere or other.
6) I'm debugging on someone else's workstation
I only really work with vim in a terminal, so doing it over SSH isn't actually all that noticeable. It does gets to be a problem when the latency is > 200ms
> Why would you develop software over SSH is seriously beyond me.
I love that this straw-man argument pops up in every thread I read about editing text or IDE debate.
As someone who leverages SSH in their average work day I can explain my personal reasons. Let me be clear; this is likely not the way you work but it is how I work. I am not defending the merits of this for you but that they warrant my approval. If any debate is to be made in this it is that all users have a choice and those who prefer SSH should have every right to use it irregardless of any unemphatic assertions to the contrary.
I have a Linux desktop that has two very nice and pretty monitors. Given a choice I would wish my development to take place on that machine. However, the development I do is on a work computer that happens to be a small Mac Laptop (I don't get to choose the hardware I must develop on). Of all the different methods to edit files I found that SSH into the laptop from the Linux box to be the most efficient and eloquent solution while still keeping the work information on the work computer. I edit in Vim. I test with the browser running on the Mac. I can clearly see and manipulate the source on the pretty monitor while seeing the results on the little LCD screen.
Pairing like this is a huge win. Instead of Forcing a pair partner to wait for me to Alt-Tab the right screen they can connect via SSH (tmate.io) and on their end have their terminal on one monitor and the Zoom / screen share on the other. This way they can edit or watch and see the result without any ask to Alt-Tab. I can read the code while they look at the result. It is truly asynchronous code-pairing.
I love that this straw-man argument pops up in every thread I read about editing text or IDE debate.
As someone who leverages SSH in their average work day I can explain my personal reasons. Let me be clear; this is likely not the way you work but it is how I work. I am not defending the merits of this for you but that they warrant my approval. If any debate is to be made in this it is that all users have a choice and those who prefer SSH should have every right to use it irregardless of any unemphatic assertions to the contrary.
I have a Linux desktop that has two very nice and pretty monitors. Given a choice I would wish my development to take place on that machine. However, the development I do is on a work computer that happens to be a small Mac Laptop (I don't get to choose the hardware I must develop on). Of all the different methods to edit files I found that SSH into the laptop from the Linux box to be the most efficient and eloquent solution while still keeping the work information on the work computer. I edit in Vim. I test with the browser running on the Mac. I can clearly see and manipulate the source on the pretty monitor while seeing the results on the little LCD screen.
Pairing like this is a huge win. Instead of Forcing a pair partner to wait for me to Alt-Tab the right screen they can connect via SSH (tmate.io) and on their end have their terminal on one monitor and the Zoom / screen share on the other. This way they can edit or watch and see the result without any ask to Alt-Tab. I can read the code while they look at the result. It is truly asynchronous code-pairing.
ssh'ing into an AWS box to share a tmux session is a great way to pair program.
Bang on. I didn't start with loads of plugins, but the ones I'm installing are ones to _help_ with being a fast text editor, such as UltiSnips. I don't install plugins to add functionality that should be performed from a shell. What's the point? You're only a Ctrl-Z or a :terminal away