Feature/linter

[montegoulding]

@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.

[peter-b]

@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).

[montegoulding]

OK, sure

[montegoulding]

@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.

[montegoulding]

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.

[peter-b]

@montegoulding Thanks for this -- it looks really nice. :)

Of course now it needs to learn to talk to lc-compile :laughing:

[montegoulding]

Good Idea about lc-compile... I guess we might need to expect them to clone the repo for that...

[montegoulding]

@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

[peter-b]

@montegoulding The output of lc-compile is completely parseable... what problems are you having with it? Are you running from develop branch?

[montegoulding]

I haven't tried that yet. What I meant was to get it to stop after checking syntax.

[peter-b]

I think it should stop if you don't specify --output.

[montegoulding]

oh, cool, I'll see what I can come up with

[peter-b]

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. ;-)

[montegoulding]

But I want it now ;-)

[montegoulding]

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.

[montegoulding]

@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.