Skip to search.

Breaking News Visit Yahoo! News for the latest.

×Close this window

jslint_com · This group has moved to Google Plus.

The Yahoo! Groups Product Blog

Check it out!

Group Information

  • Members: 584
  • Category: JavaScript
  • Founded: Mar 7, 2008
  • Language: English
? Already a member? Sign in to Yahoo!

Yahoo! Groups Tips

Did you know...
Hear how Yahoo! Groups has changed the lives of others. Take me there.

Messages

Advanced
Messages Help
Messages 2268 - 2297 of 3202   Oldest  |  < Older  |  Newer >  |  Newest
Messages: Show Message Summaries Sort by Date ^  
#2268 From: Satyam <satyam@...>
Date: Tue Jun 7, 2011 8:46 am
Subject: Has JSLINT.tree changed?
satyamutsa
Send Email Send Email
 
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

#2269 From: "Merlin" <g7awz@...>
Date: Tue Jun 7, 2011 9:56 am
Subject: Re: Has JSLINT.tree changed?
harry152566
Send Email Send Email
 
--- 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:

#2270 From: "Merlin" <g7awz@...>
Date: Tue Jun 7, 2011 10:02 am
Subject: Re: Has JSLINT.tree changed?
harry152566
Send Email Send Email
 
--- 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"

#2271 From: "Deva Satyam" <satyam@...>
Date: Tue Jun 7, 2011 11:04 am
Subject: Re: Has JSLINT.tree changed?
satyamutsa
Send Email Send Email
 
--- 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.

#2272 From: Joshua Bell <josh@...>
Date: Tue Jun 7, 2011 4:21 pm
Subject: Re: [jslint] Re: Has JSLINT.tree changed?
inexorabletash
Send Email Send Email
 
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]

#2273 From: "Merlin" <g7awz@...>
Date: Tue Jun 7, 2011 4:39 pm
Subject: Re: Has JSLINT.tree changed?
harry152566
Send Email Send Email
 
--- 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"
                             }
                         ]
                     }
                 }
             ]
         }
     ]
}

#2274 From: "Douglas Crockford" <douglas@...>
Date: Tue Jun 7, 2011 7:19 pm
Subject: Re: Has JSLINT.tree changed?
douglascrock...
Send Email Send Email
 
--- 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.

#2275 From: "Douglas Crockford" <douglas@...>
Date: Tue Jun 7, 2011 7:30 pm
Subject: Double negative
douglascrock...
Send Email Send Email
 
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?

#2276 From: Erik Eckhardt <erik@...>
Date: Tue Jun 7, 2011 7:47 pm
Subject: Re: [jslint] Double negative
vorpalmage
Send Email Send Email
 
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]

#2277 From: John Hawkinson <jhawk@...>
Date: Tue Jun 7, 2011 7:59 pm
Subject: Re: [jslint] Double negative
john.hawkinson
Send Email Send Email
 
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

#2278 From: Erik Eckhardt <erik@...>
Date: Tue Jun 7, 2011 8:28 pm
Subject: Re: [jslint] Double negative
vorpalmage
Send Email Send Email
 
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]

#2279 From: John Hawkinson <jhawk@...>
Date: Tue Jun 7, 2011 8:37 pm
Subject: Re: [jslint] Double negative
john.hawkinson
Send Email Send Email
 
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

#2280 From: "Deva Satyam" <satyam@...>
Date: Tue Jun 7, 2011 9:12 pm
Subject: Re: Has JSLINT.tree changed?
satyamutsa
Send Email Send Email
 
--- 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.

#2281 From: Erik Eckhardt <erik@...>
Date: Tue Jun 7, 2011 10:47 pm
Subject: Re: [jslint] Double negative
vorpalmage
Send Email Send Email
 
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]

#2282 From: "spence.randall@..." <randall@...>
Date: Wed Jun 8, 2011 3:05 am
Subject: Re: Double negative
spence.randa...
Send Email Send Email
 
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?
>

#2283 From: "Merlin" <g7awz@...>
Date: Wed Jun 8, 2011 12:26 pm
Subject: Re: Double negative
harry152566
Send Email Send Email
 
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?
>

#2284 From: "Douglas Crockford" <douglas@...>
Date: Thu Jun 9, 2011 7:38 am
Subject: Tolerate
douglascrock...
Send Email Send Email
 
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.

#2285 From: Jérôme DESPATIS <jerome@...>
Date: Thu Jun 9, 2011 7:59 am
Subject: jslint options specified in .js files
jdespatis
Send Email Send Email
 
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@...

#2286 From: Jérôme DESPATIS <jerome@...>
Date: Thu Jun 9, 2011 8:10 am
Subject: Error in reports but JSLINT.errors is empty
jdespatis
Send Email Send Email
 
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@...

#2287 From: "Merlin" <g7awz@...>
Date: Thu Jun 9, 2011 11:09 am
Subject: Re: Tolerate
harry152566
Send Email Send Email
 
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.

#2288 From: "Douglas Crockford" <douglas@...>
Date: Thu Jun 9, 2011 12:26 pm
Subject: Re: jslint options specified in .js files
douglascrock...
Send Email Send Email
 
--- 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.

#2289 From: "Douglas Crockford" <douglas@...>
Date: Thu Jun 9, 2011 12:32 pm
Subject: Re: Error in reports but JSLINT.errors is empty
douglascrock...
Send Email Send Email
 
--- 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.

#2290 From: Jérôme DESPATIS <jerome@...>
Date: Thu Jun 9, 2011 1:47 pm
Subject: Re: [jslint] Re: jslint options specified in .js files
jdespatis
Send Email Send Email
 
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]

#2291 From: Jérôme DESPATIS <jerome@...>
Date: Thu Jun 9, 2011 1:57 pm
Subject: Re: [jslint] Re: Error in reports but JSLINT.errors is empty
jdespatis
Send Email Send Email
 
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]

#2292 From: "spence.randall@..." <randall@...>
Date: Thu Jun 9, 2011 2:10 pm
Subject: nomen: true respects function scope?
spence.randa...
Send Email Send Email
 
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

#2293 From: kaichen67@...
Date: Thu Jun 9, 2011 2:15 pm
Subject: Re: [jslint] Tolerate
kaichen67
Send Email Send Email
 
> 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.

#2294 From: Satyam <satyam@...>
Date: Thu Jun 9, 2011 3:35 pm
Subject: Lines numbers in error report seem to be off in latest version
satyamutsa
Send Email Send Email
 
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.

#2295 From: "Douglas Crockford" <douglas@...>
Date: Thu Jun 9, 2011 5:40 pm
Subject: Re: Lines numbers in error report seem to be off in latest version
douglascrock...
Send Email Send Email
 
--- 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.

#2296 From: "Douglas Crockford" <douglas@...>
Date: Thu Jun 9, 2011 5:46 pm
Subject: Re: nomen: true respects function scope?
douglascrock...
Send Email Send Email
 
--- 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.

#2297 From: "Douglas Crockford" <douglas@...>
Date: Thu Jun 9, 2011 5:51 pm
Subject: Re: jslint options specified in .js files
douglascrock...
Send Email Send Email
 
--- 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?

Messages 2268 - 2297 of 3202   Oldest  |  < Older  |  Newer >  |  Newest
Add to My Yahoo!      XML What's This?

Copyright © 2010 Yahoo! Inc. All rights reserved.
Privacy Policy - Terms of Service - Guidelines NEW - Help