Skip to content
This repository has been archived by the owner on Jan 3, 2025. It is now read-only.

Commandline arguments for --run set in comment #135

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

Conversation

onelivesleft
Copy link
Contributor

Provides feature #134

If the file being run contains a comment of the form:

# vscode-nim arguments: <args>

then when the Nim: Run selected Nim file action is used, <args> will be added to the command line received by the binary.

@RSDuck
Copy link
Contributor

RSDuck commented Dec 3, 2019

two things which sprung to my mind:

  1. The # vscode-nim arguments: <args> syntax is very specific. I wonder if we could talk with authors of Nim extensions for other editors, if we can't come up with a shared way to specify this, if there's interest doing so.
  2. It is possible to specify arguments for individual Nim files via nims config files, which granted is another file you have to create. Unfortunately this is a lesser known features, but it has the advantage that nimsuggest and nimcheck pick it up, e.g.. they don't show an error for the code import threads, which requires the option --threads:on.

@onelivesleft
Copy link
Contributor Author

Yeah, the exact syntax is just placeholder. I did think to use something more generic, but it's not clear what the generalised keyword(s) should be. If you ditch the vscode-nim and it becomes just arguments: it becomes almost invisible - it reads just like a comment or suggestion, rather than a directive. I looked at how other things do this, for example, how you tell a linter to ignore a line, and it looks like the above. e.g. es-lint-ignore-line.

So, I think a generalised directive, that could be picked up by any IDE or editor plugin, would be the way to go, if it can be easily recognized as such by the person reading the code. I do think that it's much more usable to have it just be a comment in code rather than a setting somewhere else you have to go twiddle every time you need to test something. OTOH I may be biased, coming off the back of a package which parses the command line, which I obviously needed to mess around with a lot.

@onelivesleft
Copy link
Contributor Author

onelivesleft commented Dec 3, 2019

Oh, just groking your last point, I'm not sure if your example is off-target or you're not quite getting the purpose: this isn't for specifying arguments for the compiler; it's for specifying arguments to the program being written, when it's run. So --thread:on wouldn't come into it, nor would any other option the program needed to feed the compiler in order to compile. Those would clearly be in a config file. This is for debugging/testing the program you are currently writing, hence why embedding in a comment is much more useful.

@RSDuck
Copy link
Contributor

RSDuck commented Dec 3, 2019

oh, my bad, that was a misunderstanding on my side

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

Successfully merging this pull request may close these issues.

2 participants