3
Vote

Allow script options to be set at the file level

description

If I have a project with a large number of scripts in it, I might want to test individual scripts. Currently there is only one location to set the script arguments and/or interpreter arguments - through the project file. This means that if I want to test scripts A and B from the same project independently, I have to modify settings at the project level instead of the file level.

You can already right-click a script and choose "Start with Debugging". It would be nice if you could configure debugging properties at the file level, and "Start with Debugging" on an individual file, as opposed to F5, would use the file's debugging settings.

comments

Zooba wrote Jul 17 at 8:19 PM

I've thought about this one and the way I'd rather do it is have a launch option/menu command that pops up a dialog with, among other things, a box to enter script arguments (see #1359). This could remember the last value used for that file, which would be almost identical to what you're asking here (except that it probably wouldn't be saved in the project file, and hence would not travel to other machines...).

Does that sound like it would cover your needs?

zturner wrote Jul 17 at 8:53 PM

I do think it would be an improvement. Saving in the project file would still be nice, though.

I guess I kind of envision something like how Visual Studio handles property inheritance with native code projects. You can edit C++ options for a project, and then at the file level choose to override them or override compilation options for a specific file. So in my ideal scenario, I imagine something where at the project level you can enter whatever command line options you want, and if you do nothing, then F5 will inherit the properties from the project, but if you've overriden them (an identical UI to the Project Debug settings UI would be available for each module), then the file level options would be used.

Admittedly, I personally don't have an immediate need for this kind of flexibility, and your proposed solution would suit my needs, but it seems like generally useful functionality.