this will give you any line that has `TODO` in them, whether that was a TODO comment or just an occurrence of that word. An example:
README.md:149: * Must have one of the words: NOTE, OPTIMIZE, TODO, HACK, XXX, FIXME, or BUG
which brought this from the readme file but it was not a "real" to do.
you can then start thinking of passing regex to the grep, and trying to catch all the other annotations like FIXME, NOTE, etc. and then again you need a way to start ignoring certain files, maybe you do not want to check all the files in your node_modules, etc.
All in all, this module is just a little helper that tries to solve all these little issues.
Wouldn't 'git grep --line-number ^TODO' fix that (only match TODO at the start of a line)? Maybe with some whitespace matching if you indent your TODOs?
I don't put my TODO's at the start of lines? Usually only in single-line comments after some code.
I think a script with a few grep invocations for all code files with lines containing TODO/FIXME etc. is about right, takes minutes to set up and will work for all but the most obscure cases.
I'm not convinced that "^\s(//|#|--)\s(TODO|FIXME|XXX)\s*:" (i.e. a fairly simple regex) isn't a plausible way to do what's required of this. All the colors and everything are nice, but a simple bash script sounds eminently doable.
you can report issues in the github repo. However, if you want to ignore files and folders you need to pass those patterns to the function. For example, you want to exclude .git and .png then you need to run the command:
notes -x *.git/ -x *.png
in general if you want to exclude hidden files and folders you need to run it with -h true which excludes hidden dirs and files, so you can run
It would be so much nicer to define better defaults. Like what… 99.99% of the users are never, ever, wanting to see notes that are in the `.git` repository, nor in PNG or any other images. Even hidden dirs and files should not be searched by default I think. All this will cause nightmares to users before they start using it, like the first-poster of this thread had. Provide better defaults, make it vcs-aware (ignored files, etc…) and you will have a much more appreciated product!
It is for the same reason that `rg`/`ag`/`pt` are used nowadays instead of `grep`. 99.99% of the time, you don't want to search files that are ignored by your VCS, and you want to search recursively, and also probably in a case-insensitive way. For `grep` you have to fight with tons of options to filter out files, to enable recursivity and to ignore case. With `ag`? just `ag whatever`.
Glad to hear my comment inspired you :-) Good luck with this!
PS: Another idea: Instead of selecting manually what extensions should be used or not, you may want to try being more general, like enabling by default all text-like files, and disabling all data-like files. Maybe with `file --mime` then looking at charset value:
See https://github.com/pimterry/git-confirm, which does exactly this for TODOs, or for anything else you can spot with a regex (ignored tests, git conflict markers, etc etc). All in a single bash script you can curl directly into place, so it's independent of Node/Ruby/etc.
actually the tool is mainly based on this tool .. but the guy is not maintaining it and i decided to fill in some of the gaps. Thanks for the pointer though
I am John Postlethwait. You could have submitted a PR. That's when/how open source works. I even state that I am happy to look at incoming changes, I'm just not actively maintaining it.
This is a very minor, nigh silly, project but this sort of wanton bifurcation hurts open source's reputation and is already a huge problem in the Node community.
While I agree in general that PRs are better than forks, I don't think what you're saying is totally fair. Your choice of licensing explicitely allows forks (and almost anything else) to happen. There have been many discussions on the topic [1], and there is no easy solution.
Then, your choice of words is not ideal:
>NOTE: I no longer actively maintain this package. I'd love to get PRs to keep it going though!
If it's not maintained anymore then I as a developer don't really gain anything (bugfixes, features) by submitting a PR vs. just forking myself. So the choice to fork is understandable, even if it's not what you intended to happen.
Except it isn't a fork. It's basically two projects merged into a new one and a small blurb in the readme to that effect. Why not fork and contact John about taking the original one over? If he doesn't respond within a reasonable time, run with the fork. I don't get the sense that happened here.
I think the issue is less about license and more about what is good form and helps to keep the ecosystem a bit less cluttered.
The name on the license was changed I think that totally justifies the remarks made and they were made extremely courteous given the situation.
Forking is fine, merging two packages is fine, removing the authors name from the license (while leaving his name all over the rest of the package, which shows that there is no malicious intent, merely some confusion) is not.
Just in case you didn't know: If you used portions of Johns code, you agreed to the terms of his license. As such, you're required to include Johns name in the copyright notice, as the license specifies that thte copyright notice should be reproduced in full. You can add your own name above that, but you still have to keep the complete original copyright notice with Johns name in there [1].
Not doing that is not nice, and in the worst case could get you in legal trouble.
60 comments
[ 3.2 ms ] story [ 156 ms ] threadREADME.md:149: * Must have one of the words: NOTE, OPTIMIZE, TODO, HACK, XXX, FIXME, or BUG
which brought this from the readme file but it was not a "real" to do.
you can then start thinking of passing regex to the grep, and trying to catch all the other annotations like FIXME, NOTE, etc. and then again you need a way to start ignoring certain files, maybe you do not want to check all the files in your node_modules, etc.
All in all, this module is just a little helper that tries to solve all these little issues.
Thanks for the pointer :)
I think a script with a few grep invocations for all code files with lines containing TODO/FIXME etc. is about right, takes minutes to set up and will work for all but the most obscure cases.
It'll easily deal with your README.md case.
It is for the same reason that `rg`/`ag`/`pt` are used nowadays instead of `grep`. 99.99% of the time, you don't want to search files that are ignored by your VCS, and you want to search recursively, and also probably in a case-insensitive way. For `grep` you have to fight with tons of options to filter out files, to enable recursivity and to ignore case. With `ag`? just `ag whatever`.
Defaults make the difference.
Thanks a lot for that, ill be looking forward to what defaults people also want to have :)
PS: Another idea: Instead of selecting manually what extensions should be used or not, you may want to try being more general, like enabling by default all text-like files, and disabling all data-like files. Maybe with `file --mime` then looking at charset value:
Example:
Thanks for the pointer
https://gitlab.com/willemmali-sh/todo
PR's/issues welcome!
https://github.com/JohnPostlethwait/fixme
This is a very minor, nigh silly, project but this sort of wanton bifurcation hurts open source's reputation and is already a huge problem in the Node community.
Then, your choice of words is not ideal:
>NOTE: I no longer actively maintain this package. I'd love to get PRs to keep it going though!
If it's not maintained anymore then I as a developer don't really gain anything (bugfixes, features) by submitting a PR vs. just forking myself. So the choice to fork is understandable, even if it's not what you intended to happen.
[1] https://arstechnica.com/information-technology/2014/10/how-d...
I think the issue is less about license and more about what is good form and helps to keep the ecosystem a bit less cluttered.
Forking is fine, merging two packages is fine, removing the authors name from the license (while leaving his name all over the rest of the package, which shows that there is no malicious intent, merely some confusion) is not.
Not doing that is not nice, and in the worst case could get you in legal trouble.
Original license: https://github.com/JohnPostlethwait/fixme/blob/master/LICENS... Your license: https://github.com/ahmadassaf/code-notes/blob/master/LICENSE...
[1] http://softwareengineering.stackexchange.com/questions/17823...
I missed that with no intention of ignoring the great work of John
https://gist.github.com/thedjinn/17c68d1e62b5594581625c016b0...
This would be pretty trivial with the Sublime CLI, for example in Python:
https://gitlab.com/willemmali-sh/todo
If not, I'd greatly appreciate some feedback, I'm newish to sh programming and CLI design in general.
https://gitlab.com/willemmali-sh/todo
Fresh off the press, please let me know if you have feature requests or find bugs.
Edit: is my tone off-putting or did I break some social norm here?