I don't download the latest version of JSLint every single time so I
don't now in which version it might have stopped working but the script
I use to detect repeated strings is no longer working.  It relied in
this part of the docs:

// You can obtain the parse tree that JSLint constructed while parsing. The
// latest tree is kept in JSLINT.tree. A nice stringication can be produced
// with

//     JSON.stringify(JSLINT.tree, [
//         'value',  'arity', 'name',  'first',
//         'second', 'third', 'block', 'else'
//     ], 4));

Does it still apply?

I use the following code:

      var strs = {},
          re = /^(first|second|third|else|block|\d+)$/;
      var traverse = function (what) {
          var k,
              v = what.arity;
          if (v === 'string' || v === 'number') {
              v = what.value;
              if (v in strs) {
                  strs[v] += 1;
              } else {
                  strs[v] = 1;
              }
          }

          for (k in what) {
              if (what.hasOwnProperty(k)) {
                  if (re.test(k)) {
                      v = what[k];
                      if (v) {
                          traverse(v);
                      }
                  }
              }
          }
      };

      traverse(JSLINT.tree);


Satyam

--- In jslint_com@yahoogroups.com, Satyam <satyam@...> wrote:
>
> I don't download the latest version of JSLint every single time so I
> don't now in which version it might have stopped working but the script
> I use to detect repeated strings is no longer working.  It relied in
> this part of the docs:
>
> // You can obtain the parse tree that JSLint constructed while parsing. The
> // latest tree is kept in JSLINT.tree. A nice stringication can be produced
> // with
>
> //     JSON.stringify(JSLINT.tree, [
> //         'value',  'arity', 'name',  'first',
> //         'second', 'third', 'block', 'else'
> //     ], 4));
>
> Does it still apply?

Yes, the tree is still being constructed.
>
> I use the following code:

--- In jslint_com@yahoogroups.com, Satyam <satyam@...> wrote:
> I use the following code:

Your code does not look correct to me.

For example, look at the tree for the program

var a = "fred", b = "jim";

Here is the tree:

var tree = {
     "value": "(begin)",
     "first": [
         {
             "value": "var",
             "arity": "statement",
             "first": [
                 {
                     "value": "=",
                     "arity": "infix",
                     "first": {
                         "value": "a"
                     },
                     "second": {
                         "value": "fred"
                     }
                 },
                 {
                     "value": "=",
                     "arity": "infix",
                     "first": {
                         "value": "b"
                     },
                     "second": {
                         "value": "jim"
                     }
                 }
             ]
         }
     ]
};

arity does not take values like "string' or "number"

--- In jslint_com@yahoogroups.com, "Merlin" <g7awz@...> wrote:
>
> --- In jslint_com@yahoogroups.com, Satyam <satyam@> wrote:
> > I use the following code:
>
> Your code does not look correct to me.
>
> For example, look at the tree for the program
>
> var a = "fred", b = "jim";
>
> Here is the tree:
>
> var tree = {
>     "value": "(begin)",
>     "first": [
>         {
>             "value": "var",
>             "arity": "statement",
>             "first": [
>                 {
>                     "value": "=",
>                     "arity": "infix",
>                     "first": {
>                         "value": "a"
>                     },
>                     "second": {
>                         "value": "fred"
>                     }
>                 },
>                 {
>                     "value": "=",
>                     "arity": "infix",
>                     "first": {
>                         "value": "b"
>                     },
>                     "second": {
>                         "value": "jim"
>                     }
>                 }
>             ]
>         }
>     ]
> };
>
> arity does not take values like "string' or "number"
>
Then, perhaps, we might have found a bug since the tree elements with values "a"
and "b" are clearly not of the same nature as those of values "fred" and "jim",
the former being identifiers the later literal values.  How could you tell which
is what? Is "jim" a literal or the identifier of a variable called "jim". 
Should I figure out that "b" must be an identifier since the "=" infix operator
cannot take a literal as a "first" (left hand side) operand?  It would be more
handy if each element has its "arity" property stated as it did before.

The code in my question used to work with some previous version (I recovered it
from a backup), the one dated 2011-03-07. So something has, indeed, changed.

On Tue, Jun 7, 2011 at 4:04 AM, Deva Satyam <satyam@...> wrote:

>
> Then, perhaps, we might have found a bug since the tree elements with
> values "a" and "b" are clearly not of the same nature as those of values
> "fred" and "jim", the former being identifiers the later literal values.
>  How could you tell which is what? Is "jim" a literal or the identifier of a
> variable called "jim".  Should I figure out that "b" must be an identifier
> since the "=" infix operator cannot take a literal as a "first" (left hand
> side) operand?  It would be more handy if each element has its "arity"
> property stated as it did before.
>

It's not emitting a full AST in the sense that you can look at the node in
the output and determine what language element it represents. That would be
handy, but I don't think that's a goal for JSLint at the moment. If that's
the level of fidelity you need, you might want to take a peek at
http://code.google.com/p/es-lab/wiki/JsonMLASTFormat

The code in my question used to work with some previous version (I recovered
> it from a backup), the one dated 2011-03-07. So something has, indeed,
> changed.


It definitely seems to have changed since I played with it last. I just ran
this experiment:

var a = ["a", a, /a/];

{
     "first": [
         {
             "value": "var",
             "arity": "statement",
             "first": [
                 {
                     "value": "=",
                     "arity": "infix",
                     "first": {
                         "value": "a"
                     },
                     "second": {
                         "value": "[",
                         "arity": "prefix",
                         "first": [
                             {
                                 "value": "a",
                                 "quote": "\""
                             },
                             {
                                 "value": "a"
                             },
                             {
                                 "value": "a"
                             }
                         ]
                     }
                 }
             ]
         }
     ]
}

Note that the string literal now has a quote member to disambiguate from the
identifier (this looks to be new since your test!), but the regex literal
doesn't have any such indicator.


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

--- In jslint_com@yahoogroups.com, Joshua Bell <josh@...> wrote:

> It definitely seems to have changed since I played with it last. I just ran
> this experiment:
>
> var a = ["a", a, /a/];
>

On JSLint Edition 2011-06-06 I have rerun your test and I see this:

{
     "value": "(begin)",
     "first": [
         {
             "value": "var",
             "arity": "statement",
             "first": [
                 {
                     "value": "=",
                     "arity": "infix",
                     "first": {
                         "value": "a"
                     },
                     "second": {
                         "value": "[",
                         "arity": "prefix",
                         "first": [
                             {
                                 "value": "a"
                             },
                             {
                                 "value": "a"
                             },
                             {
                                 "value": "a"
                             }
                         ]
                     }
                 }
             ]
         }
     ]
}

--- In jslint_com@yahoogroups.com, Satyam <satyam@...> wrote:
>
> I don't download the latest version of JSLint every single time so I
> don't now in which version it might have stopped working but the script
> I use to detect repeated strings is no longer working.  It relied in
> this part of the docs:
>
> // You can obtain the parse tree that JSLint constructed while parsing. The
> // latest tree is kept in JSLINT.tree. A nice stringication can be produced
> // with
>
> //     JSON.stringify(JSLINT.tree, [
> //         'value',  'arity', 'name',  'first',
> //         'second', 'third', 'block', 'else'
> //     ], 4));
>
> Does it still apply?

I have restored arity for literals. I had removed it because with the new type
checking stuff, it had become superfluous. Please try it now.

I am not promising stability in the tree. JSLint's first mission is to be a code
quality tool. If the quest for code quality leads me to breaking the tree, I
will break the tree.

I want to change the polarity of the left most options: white, onevar, undef,
nomen, regexp, plusplus, bitwise, newcap, strict. I think it is confusing to
have Disallow options. I think Allow/Tolerate options make more sense.

But I don't know how to make this change without creating a tremor in the force.
The quickest way would be to suddenly reverse polarity. For users on the browser
version, the [Clear Options] and [Good Parts] buttons become a single button, so
that doesn't seem a big problem.

The troublesome case is the people who have /*jslint*/ directives using those
options. Those directives would have to be edited, which is really unfortunate.

So I want to make this change, but I'm not sure it is worth the cost. Comments?

I've always wondered why the values were backward and thought it a little
confusing. I don't use them (yet) so it hasn't been an issue for me, but
figured I would weigh in. Plus I have an idea:

Instead of considering each option a value unto itself, could you require
specifying the value, such as:

onevar:true
onevar:false

This would let you maintain backwards compatibility but also let you flip
the meaning of the options you want. If each one had a proper scope, then at
the top of the entire script the "default" could be set. You could even
allow `onevar:revert` to go back to the previously-set value--whatever it
is--allowing the options to be set for portions of the script without having
to create a new function scope.

Erik

On Tue, Jun 7, 2011 at 12:30 PM, Douglas Crockford <douglas@...>wrote:

>
>
> I want to change the polarity of the left most options: white, onevar,
> undef, nomen, regexp, plusplus, bitwise, newcap, strict. I think it is
> confusing to have Disallow options. I think Allow/Tolerate options make more
> sense.
>
> But I don't know how to make this change without creating a tremor in the
> force. The quickest way would be to suddenly reverse polarity. For users on
> the browser version, the [Clear Options] and [Good Parts] buttons become a
> single button, so that doesn't seem a big problem.
>
> The troublesome case is the people who have /*jslint*/ directives using
> those options. Those directives would have to be edited, which is really
> unfortunate.
>
> So I want to make this change, but I'm not sure it is worth the cost.
> Comments?
>
>
>


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

I have been bothered by the inconsistency as well, and would
favor adopting a syntax change that is unambiguous, while permitting
the old syntax to remain for compatibility.

I don't like Erik's proposal though, I have scripts with onevar: true,
and would like them not to break.

Perhaps permitting values like 'allow' and 'deny', e.g.

/*jslint onevar: allow*/
instead of
/*jslint onevar: true*/

and

/*jslint bitwise: allow*/
instead of
/*jslint bitwise: false*/

--jhawk@...
   John Hawkinson

My proposal was possibly tainted by ignorance of exactly how the options are
used, but anyway the germ of the idea is to come up with a new syntax to
unambiguously cover the flipped meaning of the terms. That part of the idea
still seems to be valid.

John, I think you meant `deny` in your second example below. I tweaked it
for you.

Erik

On Tue, Jun 7, 2011 at 12:59 PM, John Hawkinson <jhawk@...> wrote:

>
>
> I have been bothered by the inconsistency as well, and would
> favor adopting a syntax change that is unambiguous, while permitting
> the old syntax to remain for compatibility.
>
> I don't like Erik's proposal though, I have scripts with onevar: true,
> and would like them not to break.
>
> Perhaps permitting values like 'allow' and 'deny', e.g.
>
> /*jslint onevar: allow*/
> instead of
> /*jslint onevar: true*/
>
> and
>
> /*jslint bitwise: deny*/
> instead of
> /*jslint bitwise: false*/
>
> --jhawk@...
> John Hawkinson
>
>


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

Erik Eckhardt <erik@...> wrote on Tue,  7 Jun 2011
at 13:28:27 -0700 in <BANLkTimLBUWbqdu15RT9U4KHBM+bsTv+8w@...>:

> John, I think you meant `deny` in your second example below. I tweaked it
> for you.

No, it was as I stated it. Setting bitwise to true prohibits the
use of bitwise operators, which would imply denial. So bitwise: allow
must set bitwise to false, which permits them.

This is the very inconsistency at-issue here. "allow" means true
for onevar, but false for bitwise.

--jhawk@...
   John Hawkinson

--- In jslint_com@yahoogroups.com, "Douglas Crockford" <douglas@...> wrote:
>
> --- In jslint_com@yahoogroups.com, Satyam <satyam@> wrote:
> >
> > I don't download the latest version of JSLint every single time so I
> > don't now in which version it might have stopped working but the script
> > I use to detect repeated strings is no longer working.  It relied in
> > this part of the docs:
> >
> > // You can obtain the parse tree that JSLint constructed while parsing. The
> > // latest tree is kept in JSLINT.tree. A nice stringication can be produced
> > // with
> >
> > //     JSON.stringify(JSLINT.tree, [
> > //         'value',  'arity', 'name',  'first',
> > //         'second', 'third', 'block', 'else'
> > //     ], 4));
> >
> > Does it still apply?
>
> I have restored arity for literals. I had removed it because with the new type
checking stuff, it had become superfluous. Please try it now.

Works fine now, thanks.
>
> I am not promising stability in the tree. JSLint's first mission is to be a
code quality tool. If the quest for code quality leads me to breaking the tree,
I will break the tree.
>
Being there a good reason for doing so, I don't mind, but this seemed an
oversight.  After all, if the tree exists at all, it makes sense that it should
have enough information to make it worth it.

I will be quiet now. :)

On Tue, Jun 7, 2011 at 1:37 PM, John Hawkinson <jhawk@...> wrote:

>
>
> Erik Eckhardt <erik@...> wrote on Tue, 7 Jun 2011
> at 13:28:27 -0700 in <BANLkTimLBUWbqdu15RT9U4KHBM+bsTv+8w@...>:
>
>
> > John, I think you meant `deny` in your second example below. I tweaked it
> > for you.
>
> No, it was as I stated it. Setting bitwise to true prohibits the
> use of bitwise operators, which would imply denial. So bitwise: allow
> must set bitwise to false, which permits them.
>
> This is the very inconsistency at-issue here. "allow" means true
> for onevar, but false for bitwise.
>
>
> --jhawk@...
> John Hawkinson
>
>
>


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

I use the /*jslint*/ directives for some of these options, so I would have to
edit these, but I think a change for the better is worth the effort. No pain, no
gain, right?

-Randall

--- In jslint_com@yahoogroups.com, "Douglas Crockford" <douglas@...> wrote:
>
> So I want to make this change, but I'm not sure it is worth the cost.
Comments?
>

I would support a change, but I think it would be desirable to continue to
support the current /*jslint*/ directive for a while, with the current polarity
convention.

A new /*options*/ directive in JSLint could observe the new switched polarity
convention.

Editing the old form in scripts into the new would be fairly simple - mainly a
matter of deleting items that are in the "good parts".  A program to do that
would be trivial.

It does, of course, involve changes in the web interface, and, in my case, in my
Widget Tester Widget, but I don't see that as a problem given reasonable notice
of the new interface wording and the Edition in which JSLint itself would
change.

--- In jslint_com@yahoogroups.com, "Douglas Crockford" <douglas@...> wrote:
>
> I want to change the polarity of the left most options: white, onevar, undef,
nomen, regexp, plusplus, bitwise, newcap, strict. I think it is confusing to
have Disallow options. I think Allow/Tolerate options make more sense.
>
> But I don't know how to make this change without creating a tremor in the
force. The quickest way would be to suddenly reverse polarity. For users on the
browser version, the [Clear Options] and [Good Parts] buttons become a single
button, so that doesn't seem a big problem.
>
> The troublesome case is the people who have /*jslint*/ directives using those
options. Those directives would have to be edited, which is really unfortunate.
>
> So I want to make this change, but I'm not sure it is worth the cost.
Comments?
>

The options have been revised to make their definitions more consistent. JSLint
will now do the Good Parts by default. The options will now relax its rules,
making it more tolerant of popular bad practices. The option onevar has been
removed, replaced with the option vars, which has the opposite polarity. These
options have reversed their meanings:

  bitwise     Tolerate bitwise operators

  newcap      Tolerate uncapitalized constructors

  nomen       Tolerate dangling _ in identifiers

  plusplus    Tolerate ++ and --

  regexp      Tolerate . and [^...] in /RegExp/

  sloppy      Tolerate missing 'use strict' pragma

  undef       Tolerate misordered definitions

  vars        Tolerate multiple var statements

  white       Tolerate sloppy spacing

The other options continue to work as before.

The Good Parts button is no longer needed and was removed.

Please let me know if you find any problems.

Hello,

I'm using intensively jslint for every .js I code now with everything
strict to make code consistent.
First, thanks for your work to make js code looks better!

I have a routine that launches jslint for every .js I have, I
intensively uses the specific js comment:
/*global ....*/ to indicate some globals to jslint

But is there a way to indicate, like another js comment, specific
options to JSLint ?

Here's my problem indeed: I'm using the same jslint options for all .js
(the most strict ones), including strict: true

BUT, in some js codes, I can't use strict mode, (for code example, see
below)

=> As a result, it would be perfect for me to add strict: false for
those .js (that overrides the options given to jslint)

Possible to do this ?

---- example where I can't "use strict" -----
dojo.declare("my.InlineEditBox", [dijit.InlineEditBox], {
      edit: function () {
          // 'caller', 'callee', and 'arguments' properties may not be
accessed
          // on strict mode functions or the arguments objects for calls
to them
          // Hence, we have to put this into comment...
          //"use strict";

          this.previousValue = this.get("value");
          this.inherited(arguments);
      }
});


Thanks for your help

--
Jérôme Despatis
jerome@...

Hello,

I've just noticed a slight problem, in some code, there is an unused
variable items, so JSLINT.report() gives this:

<div id=errors><i>Error:</i><p><i>Unused variable:</i>
<code><u>i</u></code> <i>70 </i>
<small>'items'</small></p></div><br><div id=functions>....</div>

but at the same time JSLINT.errors is an empty array, normal ?

The fact is I just print the report for information, I rely on
JSLINT.errors.length to highlight the code if one error is detected

Thanks for your help

--
Jérôme Despatis
jerome@...

There is a new version (10.3.0) of my Widget Tester Widget at

http://tinyurl.com/5unocx  .

This should be compatible with the revised JSLint options.

Please let me know if you find any problems.

--- In jslint_com@yahoogroups.com, "Douglas Crockford" <douglas@...> wrote:
>
> The options have been revised to make their definitions more consistent.
JSLint will now do the Good Parts by default. The options will now relax its
rules, making it more tolerant of popular bad practices. The option onevar has
been removed, replaced with the option vars, which has the opposite polarity.
These options have reversed their meanings:
>
>  bitwise     Tolerate bitwise operators
>  newcap      Tolerate uncapitalized constructors
>  nomen       Tolerate dangling _ in identifiers
>  plusplus    Tolerate ++ and --
>  regexp      Tolerate . and [^...] in /RegExp/
>  sloppy      Tolerate missing 'use strict' pragma
>  undef       Tolerate misordered definitions
>  vars        Tolerate multiple var statements
>  white       Tolerate sloppy spacing
> The other options continue to work as before.
> The Good Parts button is no longer needed and was removed.
> Please let me know if you find any problems.

--- In jslint_com@yahoogroups.com, Jérôme DESPATIS <jerome@...> wrote:
> I'm using intensively jslint for every .js I code now with everything
> strict to make code consistent.
> First, thanks for your work to make js code looks better!
>
> I have a routine that launches jslint for every .js I have, I
> intensively uses the specific js comment:
> /*global ....*/ to indicate some globals to jslint
>
> But is there a way to indicate, like another js comment, specific
> options to JSLint ?
>
> Here's my problem indeed: I'm using the same jslint options for all .js
> (the most strict ones), including strict: true
>
> BUT, in some js codes, I can't use strict mode, (for code example, see
> below)
>
> => As a result, it would be perfect for me to add strict: false for
> those .js (that overrides the options given to jslint)
>
> Possible to do this ?

Yes. The instructions describe a /*jslint*/ object. It can set the options, and
it respects function scope.

--- In jslint_com@yahoogroups.com, Jérôme DESPATIS <jerome@...> wrote:
> I've just noticed a slight problem, in some code, there is an unused
> variable items, so JSLINT.report() gives this:
>
> <div id=errors><i>Error:</i><p><i>Unused variable:</i>
> <code><u>i</u></code> <i>70 </i>
> <small>'items'</small></p></div><br><div id=functions>....</div>
>
> but at the same time JSLINT.errors is an empty array, normal ?
>
> The fact is I just print the report for information, I rely on
> JSLINT.errors.length to highlight the code if one error is detected

Depending on the state of option.undef, those warnings may be suppressed.

Ok, it works great thanks,

One more remark, as Firefox throws me:
'caller', 'callee', and 'arguments' properties may not be accessed on
strict mode functions or the arguments objects for calls to them

=> Wouldn't be nice to not generate an error if "use strict" is not
present in a function that uses caller, caller or arguments ?

Because, in the following code, if 'use strict' is present, jslint is
happy but the code doesn't work.
And if not present, then jslint is not happy, but code works!

dojo.declare("my.InlineEditBox", [dijit.InlineEditBox], {
      edit: function () {
          //"use strict";
          this.previousValue = this.get("value");
          this.inherited(arguments);
      }
});


Le 09/06/2011 14:26, Douglas Crockford a écrit :
>
> --- In jslint_com@yahoogroups.com
> <mailto:jslint_com%40yahoogroups.com>, Jérôme DESPATIS <jerome@...> wrote:
> > I'm using intensively jslint for every .js I code now with everything
> > strict to make code consistent.
> > First, thanks for your work to make js code looks better!
> >
> > I have a routine that launches jslint for every .js I have, I
> > intensively uses the specific js comment:
> > /*global ....*/ to indicate some globals to jslint
> >
> > But is there a way to indicate, like another js comment, specific
> > options to JSLint ?
> >
> > Here's my problem indeed: I'm using the same jslint options for all .js
> > (the most strict ones), including strict: true
> >
> > BUT, in some js codes, I can't use strict mode, (for code example, see
> > below)
> >
> > => As a result, it would be perfect for me to add strict: false for
> > those .js (that overrides the options given to jslint)
> >
> > Possible to do this ?
>
> Yes. The instructions describe a /*jslint*/ object. It can set the
> options, and it respects function scope.
>
>


--
Jérôme Despatis
jerome@...



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

I've tried undef: true/false
and unparam: true/false

The only setting that seems to let show unused variables is unparam:
false, which seems to be the default
(I'm using the very last version from github)

And in that case this error is reported in JSLINT.report(), but
JSLINT.errors is an empty array, the latter should give more information
on this unused variable, no ?

Thanks

Le 09/06/2011 14:32, Douglas Crockford a écrit :
>
> --- In jslint_com@yahoogroups.com
> <mailto:jslint_com%40yahoogroups.com>, Jérôme DESPATIS <jerome@...> wrote:
> > I've just noticed a slight problem, in some code, there is an unused
> > variable items, so JSLINT.report() gives this:
> >
> > <div id=errors><i>Error:</i><p><i>Unused variable:</i>
> > <code><u>i</u></code> <i>70 </i>
> > <small>'items'</small></p></div><br><div id=functions>....</div>
> >
> > but at the same time JSLINT.errors is an empty array, normal ?
> >
> > The fact is I just print the report for information, I rely on
> > JSLINT.errors.length to highlight the code if one error is detected
>
> Depending on the state of option.undef, those warnings may be suppressed.
>
>


--
Jérôme Despatis
jerome@...



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

I have a small file that deals with Google Analytics, which requires you to use
_gaq as the global variable. I want to wrap this in a  function so I can declare
nomen: true for this section of the file only, but JSLint does not appear to
recognize this directive in the function scope, it only suppresses errors when
it is applied globally.

/*jslint browser: true*/
(function () {
     /*nomen: true*/
     'use strict';
     window._gaq = window._gaq || [['_setAccount', 'UA-XXXXX-X'],
['_trackPageview']];
}());

Errors:
Problem at line 5 character 12: Unexpected dangling '_' in '_gaq'.
Problem at line 5 character 26: Unexpected dangling '_' in '_gaq'.

/*jslint browser: true, nomen: true*/
(function () {
     'use strict';
     window._gaq = window._gaq || [['_setAccount', 'UA-XXXXX-X'],
['_trackPageview']];
}());

No Errors

Thanks, Randall

> The options have been revised to make their definitions more
> consistent. JSLint will now do the Good Parts by
> default. The options will now relax its rules, making it more
> tolerant of popular bad practices. The option onevar
> has been removed, replaced with the option vars, which has the
> opposite polarity. These options have reversed their
> meanings:

Please reverse this step. It's a punishment to wade through hundreds
of files and change the options meaning. Even more, because of the
"good parts" preset one might have to add several options and remove
certain others. Even with search & replace it's a lot of work, because
it has to be done for each reversed option and one has to track which
opts already were changed.

If several people add to a project, some might add a file with the
option's "new" meaning while other files still have the old opts
meaning. What a mess.

/me thinks new option names would have been a better and more
backward compatible solution. Maybe as a first step the occurrence of
an old option could set the new option accordingly and an jslint could
give an additional warning. In a few month support for old names can
be removed.

It seems the line counter is not counting  the blank lines, at least
that's what it seems in the first few lines when the code causing the
error seemed obvious, later on, I could not pinpoint what's setting it
off, if anything else is.

--- In jslint_com@yahoogroups.com, Satyam <satyam@...> wrote:
> It seems the line counter is not counting  the blank lines, at least
> that's what it seems in the first few lines when the code causing the
> error seemed obvious, later on, I could not pinpoint what's setting it
> off, if anything else is.

You did not mention which browser you are using, so I must assume it is IE.
There is a bug in IE's string.split method that causes it to lose track of blank
lines.

I used to work around Microsoft's blunders, which had the effect of making
Microsoft's implementations look better than they were, and allowed Microsoft to
go decades without fixing obvious bugs.

That strategy clearly didn't work.

So I refuse to do that anymore. I will no longer work around Microsoft's bugs.
So my advice to you is to not use any version of IE until Microsoft fixes this.

--- In jslint_com@yahoogroups.com, "spence.randall@..." <randall@...> wrote:
>
> I have a small file that deals with Google Analytics, which requires you to
use _gaq as the global variable. I want to wrap this in a  function so I can
declare nomen: true for this section of the file only, but JSLint does not
appear to recognize this directive in the function scope, it only suppresses
errors when it is applied globally.
>
> /*jslint browser: true*/
> (function () {
>     /*nomen: true*/
>     'use strict';
>     window._gaq = window._gaq || [['_setAccount', 'UA-XXXXX-X'],
['_trackPageview']];
> }());

JSLint does not recognize a /*nomen*/ directive, so it see that as a comment.
You probably meant /*jslint nomen: true*/

JSLint could have issued a warning on an unrecognized directive, but that might
also cause it to warning on comments that do not contain a strategic space.

--- In jslint_com@yahoogroups.com, Jérôme DESPATIS <jerome@...> wrote:
> One more remark, as Firefox throws me:
> 'caller', 'callee', and 'arguments' properties may not be accessed on
> strict mode functions or the arguments objects for calls to them
>
> => Wouldn't be nice to not generate an error if "use strict" is not
> present in a function that uses caller, caller or arguments ?
>
> Because, in the following code, if 'use strict' is present, jslint is
> happy but the code doesn't work.
> And if not present, then jslint is not happy, but code works!
>
> dojo.declare("my.InlineEditBox", [dijit.InlineEditBox], {
>      edit: function () {
>          //"use strict";
>          this.previousValue = this.get("value");
>          this.inherited(arguments);
>      }
> });


I am sorry. I don't understand. What exactly is the problem?