Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
TamaMcGlinn opened this issue Jun 28, 2021 · 3 comments
Open

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

TamaMcGlinn opened this issue Jun 28, 2021 · 3 comments

Comments

@TamaMcGlinn
Copy link
Contributor

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.

@TamaMcGlinn TamaMcGlinn changed the title [Feature Request]: Short summary of request [Feature Request]: Ask user to select from list Jun 28, 2021
@puremourning
Copy link
Owner

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:

  • LaunchWithSettings - supply additional input arguments to the launch config
  • SHell variables - given the provided inputs, generate/query any other data that can be determined programmatically.

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
Copy link
Contributor Author

TamaMcGlinn commented Jun 29, 2021

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
Copy link
Owner

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants