--- In jslint_com@yahoogroups.com, "Douglas Crockford" <douglas@...> wrote:
> If you are smart, you will transition to a K&R style.

I'm a little confused because I think K&R style should have functions braced
distinctly from statements, but JSLint does not allow this with the strict
whitespace option turned on.

I get an error when attempting to test out the continue option:



/*jslint continue: true */
"use strict";



Error:

Problem at line 1 character 10: Unexpected 'continue'.

/*jslint continue: true */

In these cases isn't it clearer ..

1. first if your input can be string or number, convert to a number (so ===
can be used etc)
2. check if the number isNaN
3. continue knowing your number variable really is number

Regards,

Luke

On 3 February 2011 17:16, Cheney, Edward A SSG RES USAR USARC <
austin.cheney@...> wrote:

>
>
> Classification: UNCLASSIFIED
>
> >
> > if (a !== a) {
> > }
> >
> > if (a === a) {
> > }
> >
>
> I use that logic to determine if a value, regardless of type, can become a
> number type.
>
> For instance:
>
> a = "4";
> if (Number(a) === Number(a)) // true
>
> b "4a";
> if (Number(b) === Number(b)) // false, because NaN does not equal NaN as
> they are type number, but are not a valid number.
>
> Further more you could have a comparison of functions where a number type
> is returned:
> a = function (x) {
> return (Number(x) + 3);
> }
> if (a(4) === a("4")) // true
>
> Thanks,
> Austin Cheney, CISSP
> http://prettydiff.com/
>
> Classification: UNCLASSIFIED
>
>


[Non-text portions of this message have been removed]

Classification: UNCLASSIFIED

> 1. first if your input can be string or number, convert to a number (so ===
> can be used etc)

There is no reason to change a variable type to number if mathematical
calculations are not being performed.  More often than not merely testing for
numbers is sufficient without conversion.  Additionally, unnecessary type
conversion is a security problem since math addition and string concatenation is
identical and can result in undesirable consequences or unnecessary mitigating
logic.

Austin Cheney, CISSP
http://prettydiff.com/
Classification: UNCLASSIFIED

Classification: UNCLASSIFIED

> A digital signature does not make things less worse.
> It is false security.

A digital signature is not false security.  It is the preferred means of
validating authenticity.  A digital signature should not be confused with
encryption, hashing, or public keys. 
http://en.wikipedia.org/wiki/Digital_signature

Austin Cheney, CISSP
http://prettydiff.com/
Classification: UNCLASSIFIED

This seems clearer:

a = "4";
if (isNaN(Number(a)) {

b = "4a";
if (isNaN(Number(b)) {

... but as soon as you call Number(..), you have already converted it to a
number.  (see http://www.w3schools.com/jsref/jsref_Number.asp)  Thus, in the
example ("if (Number(a) === Number(a)) {") you've actually converted it to a
number twice but still don't have a number var.  If you are going to do math
with it, you'll need to convert it a third time.

I'd recommend something like this:

a = "4";
aN = Number(a);
if (isNaN(aN)) {

... which is basically what Luke said.

Rob


-----Original Message-----
From: jslint_com@yahoogroups.com [mailto:jslint_com@yahoogroups.com] On
Behalf Of Cheney, Edward A SSG RES USAR USARC
Sent: Thursday, February 03, 2011 10:16 AM
To: jslint_com@yahoogroups.com
Subject: Re: [jslint] Suggestion for error (UNCLASSIFIED)

Classification: UNCLASSIFIED

>
> if (a !== a) {
> }
>
> if (a === a) {
> }
>

I use that logic to determine if a value, regardless of type, can become a
number type.

For instance:

a = "4";
if (Number(a) === Number(a)) // true

b "4a";
if (Number(b) === Number(b)) // false, because NaN does not equal NaN as
they are type number, but are not a valid number.

Further more you could have a comparison of functions where a number type is
returned:
a = function (x) {
     return (Number(x) + 3);
}
if (a(4) === a("4")) // true

Thanks,
Austin Cheney, CISSP
http://prettydiff.com/



Classification: UNCLASSIFIED

--- In jslint_com@yahoogroups.com, "urangatang@..." <urangatang@...> wrote:
>
> I get an error when attempting to test out the continue option:

> /*jslint continue: true */

Thanks. Please try it now.

--- In jslint_com@yahoogroups.com, "Cheney, Edward A SSG RES USAR USARC"
<austin.cheney@...> wrote:
>
> Classification: UNCLASSIFIED
>
> > A digital signature does not make things less worse.
> > It is false security.
>
> A digital signature is not false security.  It is the preferred means of
validating authenticity.  A digital signature should not be confused with
encryption, hashing, or public keys.


Nor should it be confused with security or safety. A signature does not turn
dangerous code into safe code. The problem here isn't authenticity, it is misuse
of power.

Classification: UNCLASSIFIED
> ... but as soon as you call Number(..), you have already converted it to a

That is only partially accurate.  You do perform a conversion every time you use
Number() or String(), but as long you do assign the responses of those function
back onto the variable you are testing the conversion dies with the test. For
instance:

a = "4";
if (Number(a) === a) // false, because variable a is still assigned a value of
string 4 and has not been reassigned.

Fortunately, this matter of assignment versus type is simple with strings and
numbers.  Assignment is a bit more complicated when dealing with arrays and
object literals.  For instance:

a = ["a","b","c"];
b = a; // this does not do what you might expect, instead b is now a pointer to
the contents of variable "a".

If you want to clone array "a" into array "b" you would have to do something
like the following:
a = ["a", "b", "c"];
b = [].concat(a);


The moral of this story is that testing for conversion is not the same as an
assignment and do not expect assignment to represent a uniquely assigned and
wholly contained value.

Austin Cheney, CISSP
http://prettydiff.com/
Classification: UNCLASSIFIED

> The moral of this story is that testing for conversion is not the same as an
assignment and do not expect assignment to represent a uniquely assigned and
wholly contained value.

I think the moral of the story is that you should use isNaN to test whether some
number is NaN. Testing for NaN by comparing with itself is quirky and confusing.

/Jakob


Fra: jslint_com@yahoogroups.com [mailto:jslint_com@yahoogroups.com] På vegne af
Cheney, Edward A SSG RES USAR USARC
Sendt: 3. februar 2011 19:39
Til: jslint_com@yahoogroups.com
Emne: RE: [jslint] Suggestion for error (UNCLASSIFIED)


Classification: UNCLASSIFIED
> ... but as soon as you call Number(..), you have already converted it to a

That is only partially accurate. You do perform a conversion every time you use
Number() or String(), but as long you do assign the responses of those function
back onto the variable you are testing the conversion dies with the test. For
instance:

a = "4";
if (Number(a) === a) // false, because variable a is still assigned a value of
string 4 and has not been reassigned.

Fortunately, this matter of assignment versus type is simple with strings and
numbers. Assignment is a bit more complicated when dealing with arrays and
object literals. For instance:

a = ["a","b","c"];
b = a; // this does not do what you might expect, instead b is now a pointer to
the contents of variable "a".

If you want to clone array "a" into array "b" you would have to do something
like the following:
a = ["a", "b", "c"];
b = [].concat(a);

The moral of this story is that testing for conversion is not the same as an
assignment and do not expect assignment to represent a uniquely assigned and
wholly contained value.

Austin Cheney, CISSP
http://prettydiff.com/
Classification: UNCLASSIFIED

[Non-text portions of this message have been removed]

On Thu, Feb 3, 2011 at 12:33, Douglas Crockford <douglas@...>wrote:
>
> Nor should it be confused with security or safety. A signature does not
> turn dangerous code into safe code. The problem here isn't authenticity, it
> is misuse of power.
>

So you're saying we shouldn't trust you not to misuse your power?


mathew
--
<URL:http://www.pobox.com/~meta/>


[Non-text portions of this message have been removed]

Classification: UNCLASSIFIED

> Nor should it be confused with security or safety. A signature does not turn
dangerous code into safe code. The problem here isn't authenticity, it is misuse
of power.

Security does not imply safety.  Security merely implies the degree of hardness
from distractions to the objective.  My antivirus found what it believes were
two trojans in a Java download this week from Oracle.  At least the download was
signed and authentic, because otherwise I might be concerned.

Austin Cheney, CISSP
http://prettydiff.com/
Classification: UNCLASSIFIED

Classification: UNCLASSIFIED

> Nor should it be confused with security or safety. A signature does not turn
dangerous code into safe code. The problem here isn't authenticity, it is misuse
of power.

Security does not imply safety.  Security merely implies the degree of hardness
from distractions to the objective.  My antivirus found what it believes were
two trojans in a Java download this week from Oracle.  At least the download was
signed and authentic, because otherwise I might be concerned.

Austin Cheney, CISSP
http://prettydiff.com/
Classification: UNCLASSIFIED

--- In jslint_com@yahoogroups.com, mathew <meta404@...> wrote:
> On Thu, Feb 3, 2011 at 12:33, Douglas Crockford <douglas@...>wrote:
> >
> > Nor should it be confused with security or safety. A signature does not
> > turn dangerous code into safe code. The problem here isn't authenticity, it
> > is misuse of power.
> >
>
> So you're saying we shouldn't trust you not to misuse your power?


No, I am saying that trust is important, and that a signature is not a
substitute for trust. It can in some cases stand as a token of trust. But a
signature cannot by itself make a program trustworthy.

> What I'm doing already is evaluating fulljslint.js in a secure
> context. Any attempt to access local resources *on evaluation* of the
> script would fail. BUT! What I'm not doing yet is running the JSLINT
> function in a secure context.

Indeed, I hadn't quite thought that through - thanks for being thorough!

> The last step is not terribly difficult, I just haven't had the time.
> It would involve putting the string to lint into the sandbox that
> contains the JSLINT function and then using runInNewContext to do the
> actual linting inside the sandbox

This was relatively straightforward (I think... ):
https://github.com/FND/jslint-reporter/commit/9972fdcdeb402ec859345b7801ac08dd8d\
ffd83f

I'd certainly appreciate a review though.

> Full disclosure: I'm a complete Node.js newbie myself. LintServer is
> the first piece of Node code I've ever written. As such there is
> probably a better way than mine to do the things I do.

Ditto - I'll see whether I can run this by some Node.js experts.


-- F.

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

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]

I was looking in to it for you, but with the snippet provided I was unable to
reproduce.


--- In jslint_com@yahoogroups.com, "Carlos Vadillo" <carlos.vadillo@...> wrote:
>
> I am getting this message in my code and I cannot see what is wrong. Here is
an excerpt of my code:
>
> function isValidConfig(config, reference) {
>
> var attribute;
> ...
>
>         try {
>             for (attribute in reference) {
>                 if (reference.hasOwnProperty(attribute)) {
>                     checkPropertyType(attribute, config, reference[attribute],
config[attribute]);
>                     checkPropertyValidator(attribute, config,
reference[attribute], config[attribute]);
>                 }
>             }
>         } catch (e) {
>             return false;
>         }
>         return true;
> }
>
> And I am getting this error message when using JSLint:
> Lint at line 118 character 18: Bad for in variable 'attribute'. Any ideas why
I am getting the error? What do I need to do to avoid it?
>

--- In jslint_com@yahoogroups.com, "saj14saj" <saj14saj@...> wrote:
>
> > Turn off the strict whitespace option.
> >
>
> It is not on.   JSLINT is giving the error with these settings reported
>
> /*jslint browser: true, sub: true, eqeqeq: true, windows: true, devel: true,
undef: true, maxerr: 50, indent: 4 */
>
> I specifically removed the comment from my source so there would be no
overriding the UI from the web page.
>
try using

indent: 0

--- In jslint_com@yahoogroups.com, John Hawkinson <jhawk@...> wrote:
>
>     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").
>


Hello,

I deal with a similar problem.  I am responsible for maintaining a large amount
of ASP Classic code, much of which is written in JScript.  This involves a few
instances of backwards syntax.  For instance, to set a session variable, you may
say:

Session("name") = value;

Or

Session.Contents("name") = value;

In normal syntax, it looks like you are attempting to assign a value to the
result of a function call, which doesn't make any sense.  Yet, this is how it is
done.

I have found that maintaining a private fork of JSLint has been the best answer
for this.  Doing so allows me to detect the file extension, switch on "ASP"
mode, and permit the unusual syntax for the specific objects that require it.

This process has been much smoother since JSLint now has a repository on GitHub.
Keeping up to date with the latest JSLint version has never been easier.

In your case, adding a quick preprocessing step sounds like your best bet.  If
you do this, I suggest replacing the initial "#" with a comment, rather than
stripping the lines entirely.  Doing so would preserve the correct line numbers
in JSLint's messages.

Good luck!

- Chris

I love JSLint but it's been buggy lately. One of the problems appears to be that
optional parameters for a time were made mandatory. This caused me to update my
code to what I thought was a new (overly strict) standard. Since I use this tool
to validate production code it's really frustrating that updates aren't vetted
before being released.

As a solution to this problem have you considered releasing your changes in beta
first? This could be as simple as a drop down with the options of "Last Stable"
and "Latest Beta". It doesn't even matter what it's defaulted to as long as I
have the choice.

Thanks for all your hard work on this I really appreciate it.

--- In jslint_com@yahoogroups.com, "david.herren" <david.herren@...> wrote:
>
> I love JSLint but it's been buggy lately. One of the problems appears to be
that optional parameters for a time were made mandatory. This caused me to
update my code to what I thought was a new (overly strict) standard. Since I use
this tool to validate production code it's really frustrating that updates
aren't vetted before being released.


I am not aware of bugs in JSLint. If you find any, I would be very happy to hear
about them.

I have made improvements to JSLint. Accepting those improvements will make your
programs better. This is, after all, the point.

The "indexOf polyfill" (as the kids would call it today) sample shown on
https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/Array/index\
Of
uses
two parts of JavaScript for which JSLint gives unhelpful errors:

* The void operator (coerce value to undefined)
* The Object constructor called as a function (boxes primitives)

These are not commonly used, but IMHO JSLint should either (1) parse these
forms but reject them, with explicit errors about why they are "bad parts"
or (2) accept them. The current behavior gives erroneous output which is not
helpful to users who may be validating such samples.

Examples:

var undef = void 0;
>>> Error: Problem at line 1 character 18: Expected ';' and instead saw '0'.

var s = String(123);
var n = Number("123");
var o = Object("123");
>>> Error: Problem at line 3 character 9: Missing 'new'.

Justification for including them:

* In earlier versions of ECMAScript (and implemented in many current
browsers), the Global object's "undefined" property can be successfully
assigned to, e.g. window.undefined = "foo". (ES5 defines this property with
[[Writable]]: false)

* The Object constructor called as a function parallels the String and
Number constructors-as-functions in that it boxes only if necessary. For
example, if it is desired to set a property on a value but the value may be
a string, this form can be used: o = Object(value); o.prop = "decoration";
manual boxing in this form would require either using the "new String"/"new
Number" constructors which are rejected by JSLint, or creating objects with
toString/valueOf properties to emulate the boxed value.

Justification for rejecting them:

* The void operator is very obscure, and its use makes code difficult to
understand. Alternate forms include relying on the global "undefined"
property (i.e. in browsers, window.undefined), simply using an unassigned
variable (e.g. var undef1;) or returning it from a function (e.g. var undef2
= (function() { return; }());). Further, the actual cases for generating
undefined values are rare; using typeof tests are clearer, i.e.: typeof foo
=== 'undefined'

* The use cases for Object() are rare, and explicit implementation of a
boxing mechanism in user code (while potentially fragile) will be far more
readable.

Again, I'm not advocating for approving the usage of these, merely
suggesting that JSLint could detect and explicitly reject these uses.

-- Josh


[Non-text portions of this message have been removed]

JSLint now tolerates new Array(number), but rejects all other forms of new
Array. new Array(number) was previously rejected because a large part of our
community believed that [number] and new Array(number) were equivalent, and the
sacrifice of new Array(number) was justified by that confusion. Maybe people are
smarter now.

JSLint now tolerates void 0, but no other form of void.

JSLint now does constant folding on the infix operators +-*/%. It will complain
about an operand of 0 in all cases, and complain about 1 in */%.

JSLint is looking more closely at the condition parts of if, switch, for, do,
and while statements. It will reject constants in that position except for
allowing true in while and for statements.

The JSLint options have been acting weird over the past few weeks and I finally
reproducible bug that appears both in IE 8.0.6001.18702 and Firefox 3.6.13 in
Windows XP (though I've had other problems I can't reproduce).

Steps:
- Click 'Clear All Options'
- Paste the following into the code textbox:
    /*jslint browser: true, forin: true */
- Click the JSLint button and verify there are no errors
- Select the ADSafe option
- Click the JSLint button
- Verify that you see 1 ADSafe Violation
- Uncheck the ADSafe option
- Click the JSLint button
- Verify that a slightly different Adsafe error remains.
- Refresh the page.
- Note that the Safe Subset, Disallow Undefined Variables, and Disallow dangling
_ in identifiers Options are now checked.

Hope this helps, thanks,

Dave H.

View as fixed width

Given

/*jslint strict: true, white: true, browser: true, devel: true, windows: true,
sub: true, undef: true */
/*jslint nomen: true, eqeqeq: true, plusplus: true, bitwise: true, regexp: true,
immed: true */
/*jslint maxerr: 50, maxlen: 168, indent: 4 */

var g = 1;
var h = function () {
	 "use strict";
	 return 123;
};
var r = (
	 g === 1 ?
		 h(
			 "yes"
		 ) :
		 "no"
);

Errors shown
Error:
Problem at line 13 character 13: Expected 'yes' at column 9, not column 13.

"yes"

Problem at line 14 character 9: Expected ')' at column 5, not column 9.

) :

what it looks like if I go by these

var g = 1;
var h = function () {
	 "use strict";
	 return 123;
};
var r = (
	 g === 1 ?
		 h(
		 "yes"
	 ) :
		 "no"
);

Definitely less readable. Seems to be having a problem handling function calls
as the result of an inline boolean switch.

Thanks for all the suggestions. I thought I should write
back with an update, perhaps useful to others in the same boat.

I did indeed end up with quick-and-dirty preprocessor that runs
JSLint. It's just a quick modification of fulljslint_ui.js.  While
ignoring the #-processor was easiest, I did extend it to process the
#include directive that we tend to use, for a single include file (and
fulljslint.html is modified to add that field).  Of course, doing it
this way means JSLint's line number reporting is wrong if you choose
to use the #include feature. If there was support in jslint for line
number hinting via comments, that'd be great, but I certainly don't
expect it.

Also, there's no great way to shoehorn in preprocessor error messages
this way. So it is done hackishly.

Patch follows.

--jhawk@...
   John Hawkinson
   +1 617 797 0250

--- fullinit_ui.js 2011/02/05 21:20:14 1.1
+++ fullinit_ui.js 2011/02/11 05:23:00
@@ -93,7 +93,41 @@
              show_jslint_control();
          }

-
+ function extendScript(instr) {
+     var
+  common,
+  input, output, j, m;
+
+     common = dom.q('#JSLINT_INPUTCOMMON');
+     input = instr.split('\n');
+     output = [];
+     extendScript.prelog = [];
+     for (j=0; j<input.length; j++) {
+  m=input[j].match(/^[\t ]*#include[\t ](.*)/);
+  if (m) {
+ 	    if (m[1] === '"common.jsxinc"') {
+ 	 output.push("// autoinclude: "+m[1]);
+ 	 output.push(common.getValue());
+ 	 output.push("// end autoinclude");
+ 	 extendScript.prelog.push(
+ 		    "#included common.jsxinc");
+ 	    } else {
+ 	 extendScript.prelog.push(
+ 		    "ignoring #include of " + m[1]);
+ 	    }
+  } else {
+ 	    m=input[j].match(/^[\t ]*#/);
+ 	    if (m) {
+ 	 output.push("// autocomment:" + input[j]);
+ 	 extendScript.prelog.push("ignoring "+input[j]);
+ 	    } else {
+ 	 output.push(input[j]);
+ 	    }
+  }
+     }
+     return output.join('\n');
+ }
+
  // Restore the options from a JSON cookie.

          if (!option || typeof option !== 'object') {
@@ -123,7 +157,13 @@

  // Call JSLint and display the report.

-            lib.jslint(input.getValue(), option, output);
+     lib.jslint(extendScript(input.getValue()), option, output);
+     if (extendScript.prelog.length) {
+      output.___nodes___[0].innerHTML =
+     	    extendScript.prelog.join('<br>\n')+
+ 	    output.___nodes___[0].innerHTML;
+     }
+
              input.select();
              return false;
          });
--- fulljslint.html 2011/01/30 22:16:00 1.1
+++ fulljslint.html 2011/02/06 22:24:02
@@ -139,6 +139,17 @@
      padding: 0.5em;
      width: 100%;"></textarea>
  </p>
+<p style="background-color: transparent;">
+<textarea id="JSLINT_INPUTCOMMON" style="
+    border: 2px solid black;
+    color: black;
+    background: goldenrod;
+    font-family: monospace;
+    height: 10lines;
+    overflow: auto;
+    padding: 0.5em;
+    width: 100%;"></textarea>
+</p>
  <p>
      <input type="button" name="jslint" value="JSLint">
         

John Hawkinson <jhawk@...> wrote on Fri,  4 Feb 2011
at 01:13:04 -0500 in <201102040613.p146D4rv023023@...>:

> Date: Fri, 4 Feb 2011 01:13:04 -0500 (EST)
> Message-Id: <201102040613.p146D4rv023023@...>
> To: jslint_com@yahoogroups.com
> Subject: JSLint for not-quite-JS dialects?
> From: John Hawkinson <jhawk@...>
>
> 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").

In response to recently expressed concerns:

"Widget Tester by its very nature requires full access to the user's computer.
Recent versions have had an option to download and run the latest version of
JSLint from the JSLint website. If the JSLint website or the Directory Name
Service (DNS) were to be compromised, there would be a risk of running untrusted
code. For that reason, Widget Tester now runs JSLint in a sandbox with only
limited access to the user's file system.

Widget Tester installs an auxiliary Widget, JSLint Sandbox, in the user's
Widgets Folder. JSLint Sandbox is started automatically by Widget Tester."

Widget Tester 10.0 can be downloaded from http://tinyurl.com/5unocx  .

Harry Whitfield aka Merlin.

--- In jslint_com@yahoogroups.com, "Merlin" <g7awz@...> wrote:
>
> In response to recently expressed concerns:
>
> "Widget Tester by its very nature requires full access to the user's computer.
> Recent versions have had an option to download and run the latest version of
> JSLint from the JSLint website. If the JSLint website or the Directory Name
> Service (DNS) were to be compromised, there would be a risk of running
untrusted
> code. For that reason, Widget Tester now runs JSLint in a sandbox with only
> limited access to the user's file system.
>
> Widget Tester installs an auxiliary Widget, JSLint Sandbox, in the user's
> Widgets Folder. JSLint Sandbox is started automatically by Widget Tester."
>
> Widget Tester 10.0 can be downloaded from http://tinyurl.com/5unocx  .


JSLINT likes being in a sandbox. All it needs is a source text. It does not
need, and should not be given, access to the network, the file system, or the
UI. JSLINT would be happy as a worker service.

--- In jslint_com@yahoogroups.com, "abyssoft@..." <abyssoft@...> wrote:
>
> View as fixed width
>
> Given
>
> /*jslint strict: true, white: true, browser: true, devel: true, windows: true,
sub: true, undef: true */
> /*jslint nomen: true, eqeqeq: true, plusplus: true, bitwise: true, regexp:
true, immed: true */
> /*jslint maxerr: 50, maxlen: 168, indent: 4 */
>
> var g = 1;
> var h = function () {
>  "use strict";
>  return 123;
> };
> var r = (
>  g === 1 ?
> 	 h(
> 		 "yes"
> 	 ) :
> 	 "no"
> );
>
> Errors shown
> Error:
> Problem at line 13 character 13: Expected 'yes' at column 9, not column 13.
>
> "yes"
>
> Problem at line 14 character 9: Expected ')' at column 5, not column 9.
>
> ) :
>
> what it looks like if I go by these
>
> var g = 1;
> var h = function () {
>  "use strict";
>  return 123;
> };
> var r = (
>  g === 1 ?
> 	 h(
> 	 "yes"
>  ) :
> 	 "no"
> );
>
> Definitely less readable. Seems to be having a problem handling function calls
as the result of an inline boolean switch.

It is not a bug. You have two options:

1) You can adopt a less blatently flamboyant coding style.

2) You can turn option.white off.

Your choice.