Hacker News Reader

Comment by reledi | Hacker News Reader

This is going to be handy for code reviews - thanks!

edit: My thoughts after using it.

- vim-github-commit doesn't use inline comments, the comment goes at the end of the file on GitHub, although it does say which line it refers to. I prefer GitHub's inline comments via the web interface.

- Your comment is added to whatever commit the current line was introduced in. This isn't bad, but it can be confusing if you go to GitHub and realize you wanted to comment on that line in the current version, not some version from 6 months ago.

- The comment cannot be edited or deleted (as far as I can tell), whereas you can do both if you make a comment via the web interface.

Here's how it compares to a regular comment on GitHub: http://i.imgur.com/QsDNOSu.png

View on HN

Thanks for the feedback!

You're absolutely correct - and the reason I did it that way: easier to accomplish for the first version. I have the intention to take a stab at implementing inline comments, but it's not that simple. For comment to be inline, a line index in the GitHub diff has to be specified. More information about that particular API method: http://developer.github.com/v3/repos/comments/#create-a-comm...

You can delete these kind of comments by clicking "Show lines notes below" checkbox and proceeding from there.

Thanks for building the plugin, I'm going to keep it installed because it's still useful in its current state, though I look forward to inline comments.

Also thanks for the "show line notes" tip, knowing that I can edit or delete the comments will make me more likely to use the plugin.

Amazingly, spajus already implemented that (and, I, of course, merged it) :)

https://github.com/mmozuras/vim-github-comment/pull/2

The beauty of open source and GitHub :). With that addition, I have no more issues with the plugin, works great.

One other minor nit: I think the usage video on github is way fast, I can't read what's being done and takes a few replays to understand what's going on, plus all that fast movement is actually distracting (a bit headache inducing even) and may drive people away from reading down the readme. I'd go for something at least three times slower. Well that's how I felt, at least. But really great plugin, have you looked into vim-fugitive? There might be opportunities for interplay between the two plugins (e.g. fugitive allows navigating to commit objects with :G[edit|split|vsplit].)

You're not the only one having that nit, so I'll do that :)

https://github.com/mmozuras/vim-github-comment/issues/3

I'm using fugitive myself - so I'll definitely consider interplay opportunities with it :)

Reply on news.ycombinator.com