Loading ...
Sorry, an error occurred while loading the content.

SV: [jslint] JSLint for not-quite-JS dialects?

Expand Messages
  • Jakob Kruse
    John, If the statements you mention here are the only quirks, then you could build (and possibly publish) your own “JSLint runner for ExtendScript” which
    Message 1 of 1 , Feb 3, 2011
    • 0 Attachment
      John,

      If the statements you mention here are the only quirks, then you could build (and possibly publish) your own “JSLint runner for ExtendScript” which filters them out, maybe by commenting or stringifying (// #targetengine or “#targetengine”;) to preserve line numbers, before running JSLint. Since you’re not changing any of the actual source code, that would be acceptable in my book.

      If the ExtendScript quirks extend into EcmaScript territory then JSLint is not the way to go.

      /Jakob


      Fra: jslint_com@yahoogroups.com [mailto:jslint_com@yahoogroups.com] På vegne af John Hawkinson
      Sendt: 4. februar 2011 07:13
      Til: jslint_com@yahoogroups.com
      Emne: [jslint] JSLint for not-quite-JS dialects?


      Hi, all.

      I'd like to use JSLint on Adobe's ExtendScript, a JavaScript
      variant that's used to script Adobe Creative Suite products,
      like InDesign, PhotoShop, etc. It uses the .jsx file extension.

      One of its quirks is that it has several "preprocesor"-style
      directives that can be incldued in script files, some of which
      are necessary for some scripts (e.g. "#targetengine session").

      I wrote to Douglas Crockford asking for a JSLint option to
      ignore such in JSLint, since otherwise JSLint produces a fatal error.

      He replied saying (quoted w/ permission):
      > No. JSLint is intended to improve code portability. It rejects Microsoft's
      > proprietary traps, as well as Adobe's. # is likely to mean something very
      > different in the next edition.

      Any suggestions on where I can go from here? I don't particularly
      like the idea of maintaining a private fork of JSLint for my own use
      (nor a public one!). "Don't use JSLint on this code" is unpleasant.
      Preprocessing my .jsx files before JSLint is similarly cumbersome.
      I also would like to be able to encourage other Adobe ExtendScript
      developers to use JSLint.

      Are there any good solutions anyone can recommend?

      By way of background, the preprocessor-extensions in ExtendScript are:

      #include file
      #includepath path
      #script name
      #strict on
      #target name
      #targetengine enginename

      and they are documented at
      http://www.adobe.com/content/dam/Adobe/en/devnet/pdf/illustrator/pdfs/javascript
      _tools_guide_cs3.pdf
      on page 216 and following.

      As of Edition 2011-01-28, JSLint produces:

      Error:
      Problem at line 29 character 2: A css file should begin with @charset 'UTF-8';
      #targetengine session

      Thanks very much for any thoughts.

      --jhawk@...
      John Hawkinson

      [Non-text portions of this message have been removed]
    Your message has been successfully submitted and would be delivered to recipients shortly.