Show HN: Summarise all code annotation like TODO or FIXME | Hacker News Reader

Show HN: Summarise all code annotation like TODO or FIXME

github.com

50 pointsahmadassaf58 comments

There was this too:

https://github.com/JohnPostlethwait/fixme

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.

[1] https://arstechnica.com/information-technology/2014/10/how-d...

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.

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...

thanks a lot for the pointers. I have just updated the license (actually copied Johns license and just added my name next to his)

I missed that with no intention of ignoring the great work of John

Or you could just run `git grep --line-number TODO`.

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.

Thanks for the pointer :)

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.

It'll easily deal with your README.md case.

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 easily get the colors and fancy UTF chars with an xargs | printf so a Bash/sh script should do fine.

Ack is also great for stuff like this, and easy to run as a hook or NPM thing https://beyondgrep.com

For those not working with JavaScript here's the same thing made with 40 lines of Ruby and no external dependencies.

https://gist.github.com/thedjinn/17c68d1e62b5594581625c016b0...

nice ! would be nice as well if you can pass exclusion rules for files, extensions and directories

Would be awesome if you could hit return on an issue in the list and navigate to it in your editor.

This would be pretty trivial with the Sublime CLI, for example in Python:

    import os
    os.system('subl foo.py:10')

Anyone know of a vim plugin that has similar functionality?

Isn't a script and the :cexpr command enough?

Or just :grep?

Visual Studio also has this. View -> Task List.

Pycharm and IIRC all of the IntelliJ-based IDEs also have this built in https://blog.jetbrains.com/pycharm/2013/06/working-with-todo...

How can I report issues? The tool tries to scan PNG files in the repo as well the .git folder of the repo as well.

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

    notes -h true -x *.png

Type \* to get *.

ah sweet ! thanks will update now

still not luck with me .. weird

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`.

Defaults make the difference.

i actually ignore a bunch of file extensions

   const BAD_EXTENSIONS = ["!*.jpg", "!*.jpeg", "!*.mov", "!*.mp3", "!*.gif", "!*.png", "!*.log", "!*.bin", "!*.psd", "!*.swf", "!*.fla", "!*.ico"];

I was wondering why `.png` was scanned. However, your comment makes so much sense and it will be wise to add default folders like .git as well

Thanks a lot for that, ill be looking forward to what defaults people also want to have :)

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:

    test.jpg: image/jpeg; charset=binary
    manage.py: text/x-python; charset=us-ascii

If you prefix those lines with 4 spaces, it will be interpreted as code, instead of the asterisk being interpreted as <strong>

Example:

   rm -rf *

There should be the option for an include pattern. I wanted to only check *.py files, this is very cumbersome to do with only excludes.

interesting .. will try and fix that.

Thanks for the pointer

just realised a fix where you can now:

   notes -i *.py

I hope this helps :)

Fab, cheers

Well, you've disabled issues on the repo, that's why I ask.

my bad .. did not know they were disabled

Would having a git push hook that checks for remaining/added todos with this be a good idea?

Build it! Ill test it. :)

cool ! let me know what you think

Email in my profile

I just built one, would you mind having a look at it?

https://gitlab.com/willemmali-sh/todo

PR's/issues welcome!

that was the whole idea behind building this :) automate code audit and checks via git hooks

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.

If you're using Rails, you can do `rake notes`

sh-based alternative and shameless plug:

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?

great stuff .. will try it out now and let you know

Cool, hope it's useful to you :)

Great. A 100-line python or perl (or even bash) script instead requires the whole machinery of node.js to work. Brave new world.

I'm writing an `sh`-based version, should take about 20 minutes minus the fluff.

Please share when done.

I'm starting writing now, was already too late to start last night.

I'll just leave this here:

https://gitlab.com/willemmali-sh/todo

Thanks! Will give it a shot.

Cool, hope it works well for you :)

If not, I'd greatly appreciate some feedback, I'm newish to sh programming and CLI design in general.

Pada: https://gitlab.com/willemmali-sh/todo

there is a coffee script implementation that is a bit more than 100 lines https://github.com/awebdev/node-notes/blob/master/src/notes..... I don't see why the number of lines something is written in would affect people's choice of using it

Reply on news.ycombinator.com