Closed montegoulding closed 8 years ago
@montegoulding If you would be kind enough to make any necessary updates to the readme and changelog files, I'll go ahead and merge this for 0.6.0 (and then release it).
OK, sure
@peter-b The linter now uses the server engine which will be easier for people to know how to obtain and also it has the scriptParsingErrors compiled in which saves having a file there we need to maintain. Bonus is it also now lints server scripts too. I'm just about to look at adding explicit variables as an option and then I think it's good to go.
I think it's good to go now. There's a heap of buggy generated autocomplete snippets though. Some of it may be the generator not working right but I think for the most part it's docs errors. I was wondering if it might be worthwhile implementing a syntax checker for vulcan so that any touched or new docs have their syntax checked. Perhaps an example linter too come to think of it.
@montegoulding Thanks for this -- it looks really nice. :)
Of course now it needs to learn to talk to lc-compile :laughing:
Good Idea about lc-compile... I guess we might need to expect them to clone the repo for that...
@peter-b Just looked at lc-compile and decided to stop looking ;-)
Do you think it's feasible to implement --lint
mode that pumps out a parseable {error | warning}, row, column, issue description
@montegoulding The output of lc-compile is completely parseable... what problems are you having with it? Are you running from develop branch?
I haven't tried that yet. What I meant was to get it to stop after checking syntax.
I think it should stop if you don't specify --output
.
oh, cool, I'll see what I can come up with
I was sort of joking about lc-compile support. It's hard to construct a valid command line and it depends quite heavily on project-specific contextual information. I wouldn't spend too much time on it if I was you. ;-)
But I want it now ;-)
Hmm... what if we only handled the case where the user is working on a single widget or library? We can have a module paths setting where people can enter multiple module paths and we either split by ; or something or expect the whole string to be valid options --modulepath <path1> --modulepath <path2
etc.
Perhaps a way to turn off linting via a comment line? # no linting
or something??? for the more complicated cases with dependencies among files.
@peter-b what are the chances lc-compile could read a .lcb file in from stdin if none is listed? I've had a look and it's all fairly straightforward unless we try and support multiple file dependencies but I'd like to avoid saving a temp file like I do for rev igniter if I can and use lc-compile directly instead of going via Linter.lc. One option though could be to look for a .deps file in the same directory as the file being edited.
@peter-b this PR is dependant on the grammar one. I'll keep that one merged in but you may not want the linter in the language package so I didn't want to push it on that branch. It's pretty cool though.