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

Add filter option to pickProcess command #1002

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

nkronlage
Copy link

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:

  "program": "org.chromium.chrome"

And here's the result:

image

Note, this builds on #1001 to get the config in to pickProcess

@vadimcn
Copy link
Owner

vadimcn commented Oct 1, 2023

Let's not overload program with this. The same can be accomplished via input variables.

@nkronlage
Copy link
Author

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.

@nkronlage nkronlage changed the title Use "program" as a filter to pickProcess if specified Add filter option to pickProcess command Oct 1, 2023
@vadimcn
Copy link
Owner

vadimcn commented Oct 2, 2023

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:

  • The 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.

@nkronlage
Copy link
Author

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:

image

@nkronlage
Copy link
Author

Added an error if the filter doesn't find anything:

image

My team members are very excited to use this extension for debugging. Lmk if there's any thoughts on incorporating these changes. Thanks!!

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

Successfully merging this pull request may close these issues.

None yet

2 participants