-
Notifications
You must be signed in to change notification settings - Fork 6
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
CLI support #47
Comments
Examining the code for the various actions, it seems that V-S actually re-parses the project's Soar productions each time one of the actions is executed, rather than storing any incremental representation and updating when the user changes the productions. That's interesting to me because it means that performance-wise there is very little advantage to creating an LSP; it would save the time of parsing and loading the project itself, but not of re-parsing the productions after edits. It would still be useful for syntax highlighting and for more easily plugging into supported editors, but I'm happy to know that the CLI option won't be much less performant. |
We should ensure that none of the commands run the DM compaction, which deletes unreachable parts of the DM. We could perhaps add it as a separate command, but it's not something I want too authors to accidentally run, as it could lose important work. Also, I thought that V-S would edit productions automatically when an attribute name in the DM is updated, but that is not the case as far as I can tell. Same with, for example, moving a DM node to a different folder. So are there no supported refactors? There's also no functionality to jump from some text in a production to the entry in the DM that matches it. |
To make the power of V-S accessible in contexts where users cannot or do not want to open the actual editor, CLI support for the various project actions would be very useful. I'm thinking of CI, in particular, where we could run datamap validation on every commit, but it would also become accessible for plugins in other editors. You could think of this is a baby version of the LSP idea that already provides a lot of value.
For my current purposes I really only care about the top few on the list, but I've listed what I think are all of the potentially useful commands.
I would set the return code to 0 for no issues found, 1 for some found, -1 for an execution error of some kind (unparseable project file, etc). Some of the later actions in the list might not actually be "errors", per se, so perhaps we should make this configurable.
I would print the resulting validation warnings/errors to stdout, and execution errors to stderr.
I would give the user the option to output in JSON for ingestion in other tools.
The text was updated successfully, but these errors were encountered: