killercup / grock

Grock converts your nicely commented code into a gorgeous documentation where comments and code live happily next to each other.
http://killercup.github.io/grock/
MIT License
38 stars 13 forks source link

Merge lib/languages.coffee with upstream changes #27

Closed jonruttan closed 9 years ago

jonruttan commented 9 years ago

This change merges the current state of the lib/languages.coffee file with upstream changes at https://github.com/nevir/groc/blob/5495be0a25/lib/languages.coffee.

Changes include:

killercup commented 9 years ago

Thanks mate, that looks amazing. I'll give this a try locally but I would be surprised if there was any obstacle to merging this. (BTW, I originally wanted to get rid of this method of splitting code and comments entirely, see #14 for more information.)

killercup commented 9 years ago

Thanks again, I just published this as 0.3.8 to npm!

jonruttan commented 9 years ago

Fantastic – thanks for doing that.

Yeah, I think it's a brilliant idea to just hook into the syntax highlighter and use its logic to find the comments. It's too bad highlight.js doesn't allow for that.

I tried out your feature/14-highlights branch – I see what you mean about the mass of span tags. I've been doing some tests on this branch, and I think the reason atom/highlights' runtimes were ~70% higher was because it was also loading highlight.js. After removing the require (and the lib/language.coffee stuff), I seem to be getting comparable generation times with either highlighter. I'll do some more thorough tests and post the results to the Issue #14: Evaluate Usage of Atom's Highlights page.

killercup commented 9 years ago

Wow, thanks! That's brilliant! I'm looking forward to reading your findings!

(Btw, this uses versions from about a year ago, I'm sure there are tons of updates.)

On Sun, Mar 29, 2015 at 6:06 AM, jonruttan notifications@github.com wrote:

Fantastic – thanks for doing that. Yeah, I think it's a brilliant idea to just hook into the syntax highlighter and use its logic to find the comments. It's too bad highlight.js doesn't allow for that. I tried out your feature/14-highlights branch – I see what you mean about the mass of span tags. I've been doing some tests on this branch, and I think the reason [atom/highlights]' runtimes were ~70% higher was because it was also loading highlight.js. After removing the require (and the lib/language.coffee stuff), I seem to be getting comparable generation times with either highlighter. I'll do some more thorough tests and post the results to the Issue #14: Evaluate Usage of Atom's Highlights page.

[atom/highlights]: https://atom.github.io/highlights

Reply to this email directly or view it on GitHub: https://github.com/killercup/grock/pull/27#issuecomment-87351949