Jacob, I recently got my eyes on integrating this with in ST somehow too, so let me know if I can help (I'm @tlycken at github). I was thinking that integration through SublimeLinter (http://www.sublimelinter.com/en/latest/) might be a good way to do it, but I haven't had time to look further into it.
// Tomas On Monday, September 15, 2014 8:04:07 AM UTC+2, Tony Fong wrote: > > Jacob, Mike, > > I just made a 2-line change to help you with that. You can do (block of > code as text) + (file/line info) -> Array( LintMessage,1 ) > > using Lint > ctx = LintContext() > ctx.file = file > ctx.path = path # optional, to direct include() correctly > msgs = lintstr( code, ctx, lineoffset ) # lineoffset is how you shift > from the relative line of the code to actual > > On module, however, this is tricky. Some of the Lint code needs to have > the whole module code in place to work, such as duplicated export, import > using relative path (import .Show). I'd recommend that when you care about > those Lint warnings you'd do a lint on the entire module file. I hope it > isn't too bad of a restriction that meanwhile you still get most of the > "local-level" lint functionality. > > Tony > > On Monday, September 15, 2014 6:33:59 AM UTC+7, Mike Innes wrote: >> >> We can get really nice integration for Lint.jl and Light Table – I've >> actually already got some of the GUI parts worked out, so it won't be crazy >> difficult to do. >> >> Quick question: How's Lint.jl's support for modules? For LT it's pretty >> essential that the API looks like (block of code as text) + (file/line >> info) + (module) => (warnings/errors). Of course, it's fine if I can >> wrap Lint.jl's existing functionality to have that, but current AFAICT it >> currently only works in terms of whole files. >> >> On Sunday, 14 September 2014 01:12:49 UTC-4, Viral Shah wrote: >>> >>> I wonder if these can be integrated into LightTable and IJulia, so that >>> they always automatically are running in the background on all code one >>> writes. >>> >>> -viral >>> >>> On Sunday, September 14, 2014 8:38:09 AM UTC+5:30, Spencer Russell wrote: >>>> >>>> Any comments on how Lint.jl and @astrieanna's also-awesome TypeCheck.jl >>>> relate? Are you two working together, or are there different use cases for >>>> the two libraries? >>>> >>>> >>>> peace, >>>> s >>>> >>>> On Sat, Sep 13, 2014 at 3:34 PM, Tony Fong <tony.h...@gmail.com> wrote: >>>> >>>>> Fellow Julians, >>>>> >>>>> I think it is time to post an update on Lint.jl >>>>> <https://github.com/tonyhffong/Lint.jl>, as it has improved quite a >>>>> bit from the initial version I started about 3 months ago. >>>>> >>>>> Notable new features >>>>> >>>>> - Local variable type tracking, which enables a range of features, >>>>> such as >>>>> - Variable type stability warning within a function scope. >>>>> - Incompatibility between type assertion and assignment >>>>> - Omission of returning the constructed object in a type >>>>> constructor >>>>> - Check the call signature of a selected set of methods with >>>>> collection (push!, append!, etc.) >>>>> - More function checks, such as >>>>> - repeated arguments >>>>> - wrong signatures, e.g. f( x::Array{Number,1} ) >>>>> - Mispelled constructor (calls new but the function name >>>>> doesn't match the enclosing type) >>>>> - Ability to silence lint warning via lintpragma() function, e.g. >>>>> - lintpragma( "Ignore unstable type variable [variable name]" ) >>>>> - lintpragma( "Ignore Unused [variable name]" ) >>>>> >>>>> Also, there is now quite a range of test scripts showing sample codes >>>>> with lint problems, so it's easy to grep your own lint warnings in that >>>>> folder and see a distilled version of the issue. >>>>> >>>>> Again, please let me know about gaps and false positives. >>>>> >>>>> Tony >>>>> >>>> >>>>
