
Debugging in Vim - dstein64
https://www.dannyadam.com/blog/2019/05/debugging-in-vim/
======
caymanjim
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
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?

~~~
caymanjim
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.

------
arunc
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....](https://ftp.gnu.org/old-
gnu/Manuals/gdb/html_chapter/gdb_19.html)

~~~
wgml
GDB 8.3, just released [1], introduced support for syntax highlighting.

[1] [https://lists.gnu.org/archive/html/info-
gnu/2019-05/msg00007...](https://lists.gnu.org/archive/html/info-
gnu/2019-05/msg00007.html)

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

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

~~~
michaelmrose
Elisp has a pretty good debugger just saying.

------
passthejoe
Having a terminal in Vim is very convenient.

------
AlexCoventry
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...](https://github.com/emacs-
mirror/emacs/blob/master/etc/NEWS.18#L127)

~~~
magpi3
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.

~~~
butteroverflow
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.

~~~
commandlinefan
> 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.

~~~
heavenlyblue
>> 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?

~~~
KaiserPro
> 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

