Open nkronlage opened 9 months ago
Let's not overload program
with this. The same can be accomplished via input variables.
Good idea. How does this look?
Note, I couldn't find a way to access the config's initCommands from the input variable so you have to duplicate them. LMK if you know of a way to pass those around.
Note, I couldn't find a way to access the config's initCommands from the input variable so you have to duplicate them. LMK if you know of a way to pass those around.
Ah, I was not aware of this difference in the command invocation. I can think of a couple of ways of doing it:
resolveDebugConfiguration
function gets called immediately before the variable resolution, so it could stash a reference to the current DebugConfiguration in a global variable or in extension context,resolveDebugConfiguration
actually performs its own variable resolution (things like ${dbgconfig:...}
and ${cargo:...}
), which could be extended.On the other hand, standard variable resolution is, well, standard. So I'm kinda leaning towards the way it's implemented in your PR.
Yeah, I'm fine with the duplication too. Maybe something to change later if it becomes onerous.
Also, added a try/catch around the process list call to pop up an error if the command fails:
Added an error if the filter doesn't find anything:
My team members are very excited to use this extension for debugging. Lmk if there's any thoughts on incorporating these changes. Thanks!!
I work in the Chromium code base which uses several different processes.
It'd be very convenient if the pickProcess list was filtered to just the processes I care about.
Here's a potential change to let you filter the process list by using the existing "program" option.
Here's what I put in my launch config:
And here's the result:
Note, this builds on #1001 to get the config in to pickProcess