Implemented a LiveCode builder linter.

[montegoulding]

@peter-b I went ahead and did it as it was easier than I anticipated ;-)

There's no dependency management other than global module paths. I think it's still useful for widget and library implementation though. To handle project specific deps I was wondering about a .deps file.

The .deps file would need to be parsed to replace the working file name with the temp file name and if it exists otherwise just use the temp file by itself. This way you could run lc-compile <other options> --deps <file list> > .deps to get the file. The linter would just look for the file next to the file being edited.

[montegoulding]

@peter-b I had a little play with your example of module dependencies and came up with a simple solution. The linter now auto includes and creates a directory next to the file being edited named .lci. The linter while not outputting .lcm files is still outputting .lci so these files are being updated as you work. As a result you will almost always have all your lci files up to date. You may get an error at first if you start editing a file that has a dependency but all you need to do is touch the one it has a dependency on and all is good again. Have a play with it and let me know what you think.

[peter-b]

@montegoulding This isn't totally insane, probably... :confused: :interrobang: :grimacing:

At a fundamental level, one of the big challenges with LiveCode Builder (going forward) is that the valid syntax within a module will become dependent on the other modules that it imports. Therefore it'll become difficult to do syntax check ignoring dependencies. (At the moment we could, in theory, do a context-free syntax check because, at the moment, we don't do use-dependent syntax -- all syntax is compiled into the compiler).

I was discussing this sort of thing with @runrevmark this morning. We were thinking that it would be a good idea to add a lc-build tool or something that takes care of a lot of this stuff for you.

In the shorter term, I don't know how to do deal with this nicely, yet. :-/ I feel like a lot of this stuff should come with a "experimental stuff that is likely to break and certain to change" warning...!

[peter-b]

@montegoulding With my package maintainer hat on, could I get you to fix up your git commit messages for this PR, please?

Each commit's log message should be in the following format:

<one line summary of changes, with at most 79 characters (50 if possible)>

<more detailed explanation, in paragraphs, wrapped at 79 characters>

I'm afraid I'm going to start being a stickler about this for the atom-language-livecode repository. If you don't follow the format it breaks a lot of tools that I prefer to use. Thanks.

[montegoulding]

Closing will reopen when I've squashed these commits