31–40 of 44 posts
Is there any advantage here over using Ag or Awk or similar: ag "(TODO|FIXME)"
Earlier quoted context omitted.
This library is also doing regex matching, so that you don't have to worry about matches that exist outside of comments... But like you said...you could always use fgrep (and most of us probably don't have "TODO" outside of comments anyways).
If you have TODO outside of comments which are false positives, you need to see those, and weed them out along with the true TODO items. This TODO scanner project is completely, utterly, pointless.
I've been using a one-liner git alias to do this for a while now. Works really well. It uses git grep for grepping/colouring the output and sed to remove prefixed whitespace.
If CLI regex matching (grep, ag, git grep, pt, ack...) works for you, I would stick with it ;)
This functionality is already built into every major OS and this new tool isn't any easier to use than the existing ones: Linux / UNIX: grep -n TODO *.js Windows: find /n "TODO" *.js
This library is also doing regex matching, so that you don't have to worry about matches that exist outside of comments... But like you said...you could always use fgrep (and most of us probably don't have "TODO" outside of comments anyways).
However it should be noted that regex isn't the right tool for parsing source code to begin with. There could be instances in that code where false positives are matched. And there are already known instances where positives are missed (namely "//" comments). So if you really want to exclude anything that isn't a comment then the only accurate way to do so would be full source code parsing. Failing that, it's better to match all instances since "TODO" generally isn't a string that occurs frequently outside of comments (unless it's a visual prompt to the user, eg
alert('TODO: this feature hasn't been implemented yet')
For ST2: https://github.com/SublimeLinter/SublimeLinter-for-ST2#subli...
For ST3: https://github.com/SublimeLinter/SublimeLinter-annotations
Earlier quoted context omitted.
If you have TODO outside of comments which are false positives, you need to see those, and weed them out along with the true TODO items. This TODO scanner project is completely, utterly, pointless.
There is no need for your second line. Your first line is a valid, relevant opinion. The second one has no use but to belittle the OP (or anyone else who has written a TODO scanner). You're being a dick, and missing the forest for the trees while you're at it. This project can be integrated into a larger gulp workflow, for example. It also has the ability to write the output to custom formats.
There are probably other use cases, but overall, if cli regex works great for you, stick with it.
Regarding if Leasot is pointless or not, well everyone is entitled to their own opinion (kazinator). In the greater sense I guess the world needs more todo doers than todo parsers ;)
looks great, any plans on integrating with github issues? the watson[1] gem (for ruby) has a nice feature list you could go off of. leasot + some of those features might be more suitable for people who want to stay in npmland [1]: https://github.com/nhmood/watson-ruby
In github issues you mean exporting a TODO to a github issue? If so, I don't think that belongs in Leasot, but rather an external tool for creating/manipulating Github issues (And I'm sure that kind of tool exists).
Earlier quoted context omitted.
1. thats a moot point because it doesn't explain why other people might want to use it. 2. $ alias grep="grep --color" 3. it would be even easier to extend grep via pipes. Plus pipes are langauge agnostic where as extending this tool requires knowledge of Python As a personal project, this is fine. But I really don't see the point in anyone else using it when it's slower than existing tools, no more user friendly, re…
Leasot is written in Node.js. Regarding pretty output - that could definitely be argued, but Leasot also allows for different reporters, say you want the output in JSON/XML for an external tool. That is extendable, whereas grep over regex in CLI is fast & powerful but not as flexible
Ah yes, my mistake. Though being written in Javascript makes it even worse for requiring dependencies as at least Python ships with most distros default install.
> Regarding pretty output - that could definitely be argued, but Leasot also allows for different reporters, say you want the output in JSON/XML for an external tool. That is extendable, whereas grep over regex in CLI is fast & powerful but not as flexible
I'd already addressed that point. UNIX pipes allow you to extend grep using any language (including Javascript / node.js) you want. Leasot if only extendible if you already know Javascript and node.js. Plus there are plenty of CLI tools available that can read list input from STDIN and spit out JSON or XML - so you don't even need to learn how to program to convert data files.
I've lost count of the number of times I've seen people write multi-functional programs to solve problems that would have been quicker (both in development time, and execution) to pipe a couple of existing programs together. Heck, I've even fallen into this trap myself before.
Earlier quoted context omitted.
This library is also doing regex matching, so that you don't have to worry about matches that exist outside of comments... But like you said...you could always use fgrep (and most of us probably don't have "TODO" outside of comments anyways).
grep supports regular expressions as well (hence it's name: http://en.wikipedia.org/wiki/Grep ). In fact GNU grep even has support for PCRE. However it should be noted that regex isn't the right tool for parsing source code to begin with. There could be instances in that code where false positives are matched. And there are already known instances where positives are missed (namely "//" comments). So if you really wa…
Even if you build that tool (which handles many languages) - it has an extra headache cost with the parsing time, which might be really slow for large projects.
I actually started Leasot with Javascript AST checking which never misses TODOS but is very hard to extend to other languages, as well as parsing speed was a magnitude slower.
Earlier quoted context omitted.
grep supports regular expressions as well (hence it's name: http://en.wikipedia.org/wiki/Grep ). In fact GNU grep even has support for PCRE. However it should be noted that regex isn't the right tool for parsing source code to begin with. There could be instances in that code where false positives are matched. And there are already known instances where positives are missed (namely "//" comments). So if you really wa…
Yep, truly avoiding false positives and capturing all todos you would need to really parse the source code (perhaps creating an AST or lexical parsing). Even if you build that tool (which handles many languages) - it has an extra headache cost with the parsing time, which might be really slow for large projects. I actually started Leasot with Javascript AST checking which never misses TODOS but is very hard to extend…
This isn't a dig, it's just something I've genuinely never stumbled across in 2 decades of programming so wondered if there's a culture out there I've missed.