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 run_recent #1440

Open
phcerdan opened this issue Feb 1, 2025 · 1 comment
Open

Add run_recent #1440

phcerdan opened this issue Feb 1, 2025 · 1 comment

Comments

@phcerdan
Copy link

phcerdan commented Feb 1, 2025

Problem Statement

run_last() is fantastic, however, I find myself switching over a couple of targets while debugging.

Would it be possible to add something similar to run_last() but picking from a history of recently run commands? run_recent, run_from_history... naming is hard.

I know there is the option to use .vscode/launch.json for long-term persistent targets.

Possible Solutions

run_recent() will allow to select from a list of recently run targets.

Considered Alternatives

I can write down my targets in .vscode/launch.json for long-term, but something lasting just for my current-session without extra config is very appealing

@mfussenegger
Copy link
Owner

mfussenegger commented Feb 5, 2025

I'm a bit mixed on this as it seems a bit of a niche case to temporarily jump between a couple of targets but open for more feedback on this.

Note that this could be built outside with the same approach you use to have run_last re-use already evaluated configs (#1025 (comment))

Potential options:

  • Don't include
  • Include via run_last({ pick_history = true }) or something like that
  • Could also address the other issue and additionally have a reevaluate = false and store both resolve and unresolved configs
  • Could make it easier to write down the targets in .vscode/launch.json by populating the c (for config) register with the active or last session's config in JSON format.
  • Others?

What I'd definitely like to avoid is having lots of config options for this. So if it gets added it would need a fixed size (5-10?) and a fixed retention policy (frecency?) and any further customization would defer to re-implement it using the listener approach

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

No branches or pull requests

2 participants