GithubHelp home page GithubHelp logo

vim-delve's Introduction

vim-delve

This is a Neovim and Vim plugin for debugging Go applications using Delve. The project works a lot nicer on Neovim with the built-in terminal, so that's what we recommend. But it is decent to work with on Vim if you have Shougo/vimshell.vim installed.

If you like this project, please star it. If you feel even more generous, please follow @sebdah on Twitter!

Feature highlights

  • Go syntax highlighting of debug output (only Neovim)
  • Supports both breakpoints and tracepoints
  • Run the Delve debugger in a split view along side your code
  • Launches a Delve CLI, so all commands are supported in there
  • Leverages the Neovim terminal (only on Neovim)
  • Supports main as well as and non-main packages
  • Supports vimux optionally

animated example

Requirements

For Neovim and Vim 8, you really only need Delve to get started.

If you wish to use the vimux support, you'd need to have this plugin as well:

Requirements for Vim 7 and earlier

If you are on Vim versions older than 8, you'll also need the following two packages:

Installation

Using vim-plug, add the following to your init.vim if you're on Neovim or .vimrc, if you're on vim:

Plug 'sebdah/vim-delve'

Then reload neovim and run PlugInstall.

Commands

Command Comment
DlvAddBreakpoint Add a breakpoint at the current line.
DlvAddTracepoint Add a tracepoint at the current line.
DlvAttach <pid> [flags] Attach dlv to a running process.
DlvClearAll Clear all the breakpoints and tracepoints in the buffer.
DlvCore <bin> <dump> [flags] Debug core dumps using dlv core.
DlvConnect host:port [flags] Connect to a remote Delve server on the given host:port.
DlvDebug [flags] Run dlv debug for the current session. Use this to test main packages.
DlvExec <bin> [flags] Start dlv on a pre-built executable.
DlvRemoveBreakpoint Remove the breakpoint at the current line.
DlvRemoveTracepoint Remove the tracepoint at the current line.
DlvTest [flags] Run dlv test for the current session. Use this to debug non-main packages.
DlvTestCurrent [flags] Run dlv test for the current test or function. Use this to debug non-main packages.
DlvToggleBreakpoint Convenience method to toggle (add or remove) a breakpoint at the current line.
DlvToggleTracepoint Convenience method to toggle (add or remove) a tracepoint at the current line.
DlvVersion Print the dlv version.

Configuration

Setting Default value Comment
g:delve_backend default Defines the backend to use with Delve. Please refer to the Delve documentation for details on what you should set this value to.
g:delve_sign_group delve Set the sign group.
g:delve_sign_priority 10 Set the sign priority.
g:delve_breakpoint_sign_highlight WarningMsg Set the color profile for the sign.
g:delve_breakpoint_sign โ— Sets the sign to use to indicate breakpoints in the gutter.
g:delve_tracepoint_sign_highlight WarningMsg Set the color profile for the sign.
g:delve_tracepoint_sign โ—† Sets the sign to use to indicate tracepoints in the gutter.
g:delve_cache_path $HOME . "/.cache/" . v:progname . "/vim-delve" The path to where the instructions file for dlv is stored.
g:delve_instructions_file g:delve_cache_path ."/". getpid() .".". localtime() The instructions file name.
g:delve_enable_syntax_highlighting 1 Turn syntax highlighting in the dlv output on or off.
g:delve_enable_linenr_highlighting 0 Turn line number highlighting on or off.
g:delve_new_command vnew Control if dlv should be opened in a vertical (vnew), horizontal (new), full screen window (enew) or full screen window in new tab(tabnew).
g:delve_use_vimux 0 Sets whether to use benmills/vimux].
g:delve_project_root Override the path to use for setting breakpoints/tracepoints.

The settings above can be set in your init.vim like this:

let g:delve_backend = "native"

Frequently Asked Questions

Got an error about lldb-server on Mac OS X

If you get a message like the one below on Mac OS X, try setting g:delve_backend to native.

could not launch process: exec: "lldb-server": executa ble file not found in $PATH

Example: let g:delve_backend = "native"

Contributing to vim-delve

Contributions to the project is most welcome. I'd be happy to review and merge pull requests. If you need any directions in your implementation we can always discuss that too.

What can I do to help?

There are many things that this project need, but some examples could be:

  • I don't know if this works on Windows. If you could try it out and or make it work that would be great.
  • I haven't tested the project thoroughly on Vim, if you could do that it'd be wonderful.
  • Answer questions from users
  • Or implement new features

License

MIT Licensed software.

vim-delve's People

Contributors

alejandrodnm avatar burik666 avatar cassiobotaro avatar datsuns avatar itchyny avatar jinzhu avatar leighmcculloch avatar modood avatar rsheasby avatar sebdah avatar slax0rr avatar ueaner avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar

vim-delve's Issues

What's the best debug workflow?

I think before I tried vim-delve, it opened an interactive console.

Now when I run it, I get a lot of windows that I'm confused how to interact with: https://s.natalian.org/2021-04-11/vim-delve.mp4

What am I missing please?

Oh. I think I'm getting confused between vim-delve's DlvAddBreakpoint and vim-go's GoDebugBreakPoint. ๐Ÿคฆโ€โ™‚๏ธ

Plz add a "Getting started" section to readme

This project seems cool, but after installing neovim and adding the package, I don't really know how to get started using it. If I use nvim to open the source file containing main() and try to execute DlvToggleBreakpoint I just get:

E492: Not an editor command: DlvToggleBreakpoint

I'm sure it is probably very simple, but so am I! Can I get some hints. ๐Ÿ˜„

Add support for touchbar

It would be nice to have support for touchbar present on MacBooks.
Having a dedicated set of buttons would greately simplify the user experience.

Add a command like :DlvNextBreakpoint

A great feature of some other plugins is the ability to jump to the next relevant thing. For example, with vim-signify I can jump to the next change in my current buffer. This is very useful for moving between sections of a file that are relevant to my current task.

vim-delve could benefit from a similar feature for breakpoints, something like :DlvNextBreakpoint. This would move me to the next breakpoint in the file.

When I've got a few breakpoints going, I often find myself wanting to remove one or two. This motion based command would be helpful here.

Otherwise, thanks for making the wrapper on delve! I use it every day.

Adding support for vim sessions

Hello,
while using vim-delve und using Sessions to resume my work on a project I would love to see, that vim-delve interacts with the session function and reopens every breakpoint I've set previously.

What format is DlvExec expecting arguments?

DlvExec ~/go/bin/acommand anargument

results in:

zsh:cd:1: no such file or directory: anargument

But any quoting of the command causes DlvExec to just split the buffer window.

Breakpoint location not found

Hello,

I am running a dlv exec somebin in headless mode outside of vim and then using DlvConnect to connect to delve in order to debug my executable, but my workdir is just a symlink:

/my/workdir/ -> /actual/location

Now, when I run go build .... inside /my/workdir/ this builds the exec with /my/workdir/ path, but, when vim-delve uses expand('%:p') on the file where I want to place a breakpoint it will use the /actual/location/ instead of my symlink, and of course, when delve receives break /actual/location/some.go:123 it throws a not found error.

Here is a possible solution to this issue:

function! delve#getFile()
    if !exists("g:delve_project_root")
        return expand('%:p')
    endif

    return g:delve_project_root . expand('%')
endfunction

Allow the user to set the root dir of the files, then just use this function to get the absolute file path when setting the breakpoints/tracepoints. Since this is a very specific issue, I thought I'd ask here before making a pull request, if you think that this is even worth fixing?

(Possibly) Need an example of passing go build flags to delve

MacOS 10.13.5 (tmux and iterm-2), dlv 1.0.0-rc.1, neovim v0.3.1-36-gb006771, vim-delv commit 2f2a61e

Using DlvDebug -- inferior args, my program launches and hits the expected breakpoint. locals is empty and there are no symbols for any variables. I believe I need to pass -gcflags="-N -l" to go build via dlv --build-flags.

I'm uncertain of the best way to achieve that when the entry point is DlvDebug

:DlvDebug --build-flags="-gcflags"-N -l"" -- inferior args doesn't get it done. Niether do a variety of attempts at escape fiddling.

Is there an example I have missed or what should I be doing instead ?

osx M1 chip delve fails to run in terminal

when trying to run :DlvTest from nvim in osx it fails with below message.
native backend disabled during compilation

details :
osx : mac os Monteray 12.4
chipset : M1
go version :
go version go1.17.8 darwin/arm64
dlv version :

Delve Debugger
Version: 1.8.3
Build: ac81269eef6743ac8914acd32358dbe79c79340f

nvim version

NVIM v0.7.0
Build type: Release
LuaJIT 2.1.0-beta3
Compiled by [email protected]

lua settings for the plugin :

vim.g['delve_backend']='native'

please let me know if you require more details.

Setting breakpoints/tracepoints in editor doesn't work

If I set a breakpoint in the Delve window then code execution halts as expected. However, if I set the same breakpoint using :DlvAddBreakpoint it doesn't.

Looking at my application logs I can see the debug server is creating the breakpoint when using the Delve window e.g. created breakpoint: &api.Breakpoint{ID:1...} but not when setting it in the editor. So I assume the command is not sent when using the editor.

This is when connecting to a debug server running in a Docker container using :DlvConnect localhost:2345 apiVersion=2.

This is using:

Mac OS 10.12.6
NVIM v0.3.1
Delve 1.0.0-rc.2

Help: trying to debug ncurses program

Hey,

I'm trying to debug https://github.com/gokcehan/lf and I was hoping I could get some help here. It feels though as if there is a bug in vim-delve but I'm not experienced enough in bare dlv so I'm not sure.

Using Neovim, I open a source file in one split and in another I open a Neovim's :terminal in which I run dlv --headless. It looks like that:

Alacritty:2019 04 28-22:49:53

The problem is, that when dlv --headless --listen localhost:1956 debug . is running, executing in Neovim :DlvConnect localhost:1956 seems to be making the other dlv process receive a continue command. If I don't have any breakpoints set, the debugger prompt is not usable while the debugged program is running.

Unsurprisingly, this doesn't happen when I run in a different terminal dlv connect localhost:1956.

Is this automatic continue behaviour intentional?

location not found

Hello , thanks for building this amazing tool
my delve server run on docker on address 127.0.0.1 and port 2345 and I use DlvConnect 127.0.0.1:2345 to connect to it but I get this error
image
here is my configuration on vscode that I use it to connect debugger on container from vscode and it works fine

    "version": "0.2.0",
    "configurations": [
        {
            "name": "normal",
            "type": "go",
            "request": "launch",
            "mode": "remote",
            "remotePath": "/clean_web",
            "port": 2345,
            "program": "${workspaceRoot}",
            "host": "127.0.0.1",
            "showLog": true
        },
        {
            "name": "test",
            "type": "go",
            "request": "launch",
            "mode": "remote",
            "remotePath": "/clean_web",
            "port": 4000,
            "program": "${workspaceRoot}",
            "host": "127.0.0.1",
            "showLog": true
        }
    ]

as you can see we have two configuration key named remotePath and program do we have something like that in this vim-delve ?

Feature Request: Flush writeInstructionsFile on change

I'm using Delve through vim-test. One of the problems with that integration is that vim-test is writing it's own init file and calling tests agains that.

This means that if i run tests then change my breakpoints the new breakpoints will not be picked up until I re-run vim-test. I would like to be able to use the vim-test re-run command with new breakpoints.

While I realize this is a vim-test problem, however I think this would best be solved by adding an upstream feature to keep the command file up-to-date. That would allow vim-test to instead hook into the file provided by vim-delve.

If you are amenable to this feature I think I can handle the addition of it. Please let me know.

VimLeave: E488: Trailing characters

I recently added this plugin to my vimrc and I upon neovim exit I started noticing the following error message:

Error detected while processing VimLeave Auto commands for "*":
E488: Trailing characters

If I disable this plugin, the message does not appear. Do you think this is related to this plugin?

Custom flags support

Make it possible to send custom flags like e.g. --log and --build-flags to the following commands:

  • attach
  • exec
  • debug
  • test

Add dlv exec support

Thanks for this! This looks great!

I need to execute dlv using dlv exec because I work at Google and we use Bazel, not the normal Go structure.

Is it possible to do this with vim-delve?

Command Line arguments at start of debug

Thanks for the plugin, working great when I am testing unit tests. Had a question about full debug starting from a main that takes command line arguments.

I am switching over from Visual Studio Code, and I am able to set command line args when starting the go debugging.

I was wondering if there is something similar to below or a way to set my arguments to the start of the go application that I am debugging?

Thanks,
Jim

{
    // Use IntelliSense to learn about possible attributes.
    // Hover to view descriptions of existing attributes.
    // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
    "version": "0.2.0",
    "configurations": [

        {
            "name": "Launch",
            "type": "go",
            "request": "launch",
            "mode": "debug",
            "remotePath": "",
            "port": 2345,
            "host": "127.0.0.1",
            "program": "${fileDirname}",
            "env": {"STATELOCATION": "/home/tmp"},
            "args": ["server", "-listen", ":8888", "-cluster", "dev"],
            "showLog": true
        }
    ]
}

Add note in README about help wanted

There are some things that others could help out with, like Windows support and vim support. Should maybe add a short section in the README to mention that.

Change cwd of delve process

Hi! First of all, thanks for the great plugin, it greatly improves my debugging experience :)

When I work with a console dlv, my usual debugging routine is to go to the project root and run dlv debug ./cmd/main.go there, since some of the programs expect the root current work dir.

But I don't see how to run :DlvDebug from root dir or change cwd. How could I do this?

As a workaround I managed to pass relative paths as command line options to binary, so it's not so important now.

Delve takes quite a while to load even when not loading Go files at all

As you can see from this profiler excerpt, delve takes a solid half a second to load even when loading plaintext files.

058.538  009.532  009.532: sourcing /Users/badt/.vim/plugged/vim-unimpaired/plugin/unimpaired.vim
059.444  000.655  000.655: sourcing /Users/badt/.vim/plugged/vim-surround/plugin/surround.vim
060.564  000.891  000.891: sourcing /Users/badt/.vim/plugged/vim-abolish/plugin/abolish.vim
061.084  000.332  000.332: sourcing /Users/badt/.vim/plugged/targets.vim/plugin/targets.vim
062.140  000.638  000.638: sourcing /Users/badt/.vim/plugged/vim-go/autoload/go/config.vim
063.522  000.537  000.537: sourcing /Users/badt/.vim/plugged/vim-go/autoload/go/util.vim
063.564  002.302  001.127: sourcing /Users/badt/.vim/plugged/vim-go/plugin/go.vim
067.768  003.999  003.999: sourcing /Users/badt/.vim/plugged/emmet-vim/plugin/emmet.vim
068.100  000.030  000.030: sourcing /Users/badt/.vim/plugged/goyo.vim/plugin/goyo.vim
521.377  453.067  453.067: sourcing /Users/badt/.vim/plugged/vim-delve/plugin/delve.vim

This is simply unacceptable for most Vim users on legacy hardware. And I'm running a top of the line 2015 MBP which is not particularly old as it happens.

update README for vim 8

I don't think vim 8 still needs Shougo/vimshell.vim Shougo/vimproc.vim.

If I'm right, consider updating the README?

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.