You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
it's a bitch to parse all the different readme formats... perhaps a textarea with the source would be enough (since we can all read most of the formats by site)... just enough to get a summary of an unfamiliar project
Strange, I was thinking about the exact same thing. I even submitted a ticket to github asking them to add this to their API since I need this in another project.
The big thing with this is that you need to worry about the following:
People don't all use markdown. or textile. or even a markup language. So I'd have to parse any/all of them. Or at least the two I've mentioned
People don't always standardize on one name for a readme. Readme.markdown, readme.mkdn, readme.mkdown are all valid readmes
I'd have to sanitize the readme before displaying it. And that would mean I'd have to store it in the db so it doesn't take forever on each page-load. And that would mean I need to worry about readme invalidation. Perfect.
Found a project that may be the best solution. I can look into forking it and adding missing parsers needed. I opened a bug ticket so that the project would support file extension scanning: joebeeson/embellish#1
They had a discussion on the github markup repo about how useful or useless
file extensions can be. But i think with a combination of file extension and
other methods like file header that it could be done.
Found a project that may be the best solution. I can look into forking it
and adding missing parsers needed. I opened a bug ticket so that the project
would support file extension scanning: joebeeson/embellish#1
Checking the file extension would be good enough, and then mapping these to some library for parsing.
What would need to occur is, on repository update, the readme would be detected (through use of some regex) and then turned into some standard, like, idk, html. It's sanitized and stored, then rendered whenever the user accesses the page for that package. Could be stored in a viewcache, or even just raw html that is then included via php.
Pandoc would be nice, if it compiled on my mac and didn't require 9 million other things.
Activity
ProLoser commentedon Jun 24, 2011
Strange, I was thinking about the exact same thing. I even submitted a ticket to github asking them to add this to their API since I need this in another project.
sdoney commentedon Jun 24, 2011
I independently thought the same thing. Saves a step, and the user wont have to leave the site every time to view it.
josegonzalez commentedon Jun 24, 2011
The big thing with this is that you need to worry about the following:
Readme.markdown,readme.mkdn,readme.mkdownare all valid readmessdoney commentedon Jun 25, 2011
https://github.com/github/markup
josegonzalez commentedon Jun 25, 2011
Yes, let me add that to the Gemfile so that my ruby application that indexes CakePHP code can consume markup on github.
sdoney commentedon Jun 25, 2011
just gathering the pieces together to make this happen eventually, yes i
know cakepackages is not ruby, but even i could adapt this code for php.
On Sat, Jun 25, 2011 at 10:22 AM, josegonzalez <
reply@reply.github.com>wrote:
josegonzalez commentedon Jun 25, 2011
Then do so.
ProLoser commentedon Jun 27, 2011
Found a project that may be the best solution. I can look into forking it and adding missing parsers needed. I opened a bug ticket so that the project would support file extension scanning: joebeeson/embellish#1
sdoney commentedon Jun 28, 2011
They had a discussion on the github markup repo about how useful or useless
file extensions can be. But i think with a combination of file extension and
other methods like file header that it could be done.
On Mon, Jun 27, 2011 at 4:50 PM, ProLoser <
reply@reply.github.com>wrote:
josegonzalez commentedon Jun 28, 2011
Checking the file extension would be good enough, and then mapping these to some library for parsing.
What would need to occur is, on repository update, the readme would be detected (through use of some regex) and then turned into some standard, like, idk, html. It's sanitized and stored, then rendered whenever the user accesses the page for that package. Could be stored in a viewcache, or even just raw html that is then included via php.
Pandoc would be nice, if it compiled on my mac and didn't require 9 million other things.
josegonzalez commentedon Jun 30, 2011
Is anyone working on this at the moment? I'd be happy to add you guys as contributors so we can assign things to people.