puremourning / vimspector

vimspector - A multi-language debugging system for Vim
http://puremourning.github.io/vimspector-web
Apache License 2.0
4.08k stars 171 forks source link

[Feature Request]: Ask user to select from list #421

Open TamaMcGlinn opened 3 years ago

TamaMcGlinn commented 3 years ago

Is your feature request related to a problem? Please describe. When working in Ada, the *.gpr file nearest the current file describes the possible main programs that the user may want to debug. I can write a little program that outputs a list of these possible main programs, but then I need a way to specify in the .vimspector.json file that the user should select from these. Ideally, the feature would only ask when the list is larger than 1 element, as having only a single main would be quite common.

Describe the solution you'd like

{
  "configurations": {
    "ada lldb": {
      "adapter": "CodeLLDB",
      "variables": {
        "GprMains": {
          "shell" : [ "select_ada_main", "${workspaceRoot}", "${fileBasenameNoExtension}" ]
        },
        "SelectedMain": {
          "user_list_selection": [ "*${GprMains}" ]
        }
      },
      "configuration": {
        "request": "launch",
        "program": "${SelectedMain}",
        "stopOnEntry": true,
        "initCommands": ["script import math"]
      }
    }
  }
}

Of course, that feature could be used for all other cases where the configurer knows there is a list of possible options for some value. I think this is just much more useful than being able to specify a default.

Describe alternatives you've considered I think it's possible to do the same thing as the Y/N questions regarding whether to break on exceptions being raised & caught. That is, print all the mains possible in the key, pick the first as a default, and ask for a string from the user. Yuck.

Additional context CodeLLDB sorta works for Ada code. But really this question isn't specifically about Ada; the request will be generally useful whenever you want to write a default config that reads some sort project file - it might even read a Makefile or a README.txt to find out what the mains are for your project.

puremourning commented 3 years ago

I would suggest to write something that happens before launching the debug session, and then call vimspector#LaunchWithSettings() to pass the result in as a variable.

I do this sort of thing with running the test under the cursor. You could easily write some vim script that :

  1. reads the file (e.g. using readfile()) or runs your script (e.g. system( "select_ada_main...." ))
  2. presents the options (e.g. using inputlist())
  3. launches vimspector with ${SelectedMain} pre-set, i.e. call vimspector#LaunchWithSettings( { 'SelectedMain': the_value_the_user_picked } )

Shell variables aren't really meant for this level of sophistication, and it looks like it should be easy enough to customise this for your usage. Think of it like this:

FWIW I do this sort of thing all the time with LaunchWithSettings. Often I use it for commands like "run the current test under my cursor in vimspector" etc. I use shell variables mostly for getting invariant data (like runtime paths, dependency paths, etc.) from the build system (and sometimes I use it as a hack to rebuild the binary automatically, but that's a different story).

Based on that, I think I'll close this unless you think this doesn't cover your use case?

TamaMcGlinn commented 3 years ago

It covers the use case, and I thank you for the advice. But I would still much rather see this functionality inside vimspector config files, because those are part of the actual code repository. For your use case, it would mean that anyone else opening up your vimtest-enabled repository would automatically have the ability to run the test under their cursor*, rather than having to find your vimrc files and copy in the appropriate parts into their vimrc. For my use case, it means all Ada repositories can be made automatically debuggable using vimspector.

Would you welcome a PR for this? If so, do you think my suggested syntax would work and be the easiest way to achieve this?

* Assuming we have a preset variable to get the current cursor position when debugging was started

puremourning commented 3 years ago

Hmmm, I take your point. What I actually do is have an "internal" vim plugin which contains all of the required setup that any vimspector users at work use. Most of the complexity is bundled in some custom adapter specs and some ftplugins.

But I guess this "present a list to choose from" isn't so wild. Indeed, in another branch I have a thing that allows you to do exactly this. The syntax is something like ${MyVariable:Choice1\nChoice2\nChoice3} which is presented as a list:

  1. *Choice1
  2. Choice2
  3. Choice3

That is, it splits the "default" value into a list on newline, and assumes the first one is the "default". I think it might be possible to use the recursive expansion like ${MyVariable:${Choices\}}. the code is here: https://github.com/puremourning/vimspector/blob/setup-guide/python3/vimspector/utils.py#L561-L570

Feel free to try it out.

One thing I am very wary of is the sort of inner-platform effect with adding more and more complexity to the configuration meta-language. The idea starts with simple variable substitutions and quickly starts to become some non-Turning-complete hybrid language.