parseComment() utility for Dabblet.title()

[stagas]

(This needs to be merged on top of #206).

I basically changed code/dabblet.js Dabblet.title() to use a utility that parses both the title and the comment body. I was planning to use it to create an .md in the gist for easier viewing through github (without any dabblet extension) and maybe a link to the dabblet site so the top comment could serve as a little readme for it.

It's only unit-tested because I couldn't run the site to test integration so it needs to be tested on your setup.

[stagas]

Any chance this will be merged? I ultimately want to add a README.md generator (with parseComment) and a link back to the dabblet site through github.

[LeaVerou]

Hi there,

Thanks for the contribution!

I like the idea of the possibility to create README.md when the comment is over a certain threshold of lines, but I wouldn’t want to merge such extensive changes to the codebase for a relatively minor feature.

Btw, Dabblet.title() needs to be changed anyway, in a different way: To allow titles to be specified through HTML and JS too.

[stagas]

Most of it is mocha, which is what I use and I wouldn't want to commit untested code to other people's repos, otherwise the changes are very little actually. The parseComment() function is ripped from visionmedia/dox which is used to generate docs from JSDoc style comments, which are pretty much standard nowadays. But since you're going in a different direction then I rest my case and I'll wait to see what you'll come up with. I still want a link back to dabblet from github, I'm too lazy to go manually every time and your stuff are interesting.

[LeaVerou]

A link back sounds more like something a browser extension or bookmarklet should do, not clutter every dabblet with it. There was a dabblet Chrome extension, but I don’t think it works after the Gist redesign. :/ Should be easy to update though.

[stagas]

Why do you think the convenience of a link back is clutter?

Workflow 1: write dabblet -> dabblet gets posted in gist -> appears in everyone's timeline -> people click -> nil

Workflow 2: write dabblet -> dabblet gets posted in gist -> appears in everyone's timeline -> people click -> people read description -> people see link and click it if description is interesting -> admire new interesting dabblet -> get excited about it -> share it with friends and so on

[stagas]

Not to mention the security issues of running arbitrary JS with extensions/bookmarklets while still in github.

[LeaVerou]

bookmarklets aren’t a security issue, you can check their (usually short) code and they don’t change afterwards (unless they reference external scripts).

However, you’ve started to convince me on the URL. Where do you think it should be placed? In a separate file?

[stagas]

I was referring to the JS of the dabblet itself, but I don't know the implementation I had the impression it would fetch a dabblet.js and then execute the gist contents while in github.

Yes, I was thinking of a separate file, a link.md maybe?