This sort of thing feeds my paranoia about GitHub being a giant single point of failure in the open-source world. I know the argument: Someone, somewhere has a copy of each repo checked out, so we (the nebulous "we") could reconstruct everything from the diaspora of ".git" directories. It just bothers me to think how dependent OSS has become upon GitHub.
> GitHub being a giant single point of failure What is our definition of a "point"? If you have an external hard-drive backup of your laptop, that's 2 points of failure, right? If someone else has 10 external hard-drives that they keep in different places, that's 10 points, yes? But what stops you from calling all those hard-drives "a giant single point of failure"? If all of them are destroyed, the data is lost. I j…
GitHub dropped Pygments
71–80 of 133 posts
Re: GitHub dropped Pygments
#72Re: GitHub dropped Pygments
#73I honestly don't see a problem here. They decided to change a backend library for a non-essential system in their product. Most services don't ask for permission or make announcements when they make changes like this. The approach seemed to be, if things break, people will report it and we’ll fix it. While this may not be the best approach, the number of languages supported is too high for a person to check each one…
That said, I don't think anyone will bin a candidate because Github didn't highlight his or her code properly.
Re: GitHub dropped Pygments
#74It is really easy to highlight simple things (keywords, numbers, ...). However when it comes to more complex scenarios (e.g. where the type of a word depends on the previous one) then the singleline regex based mechanism shows it weakness. Due to that many language support plugins will yield wrong results when you start to split things like function declarations over several lines, even though it's perfectly legal in the languages. Some things can be worked around with the start/end regexes, but nesting those multiple levels deep can get quite akward and I don't think that they were thought of for things beyond braces and multiline comments.
Therefore I don't know if Githubs move here is a really good choice. However I think their main motivation might be that this file format already has such a big ecosystem due to Textmate, Sublime and Atom and the parser has a high performance so that they went for it.
Re: GitHub dropped Pygments
#75Earlier quoted context omitted.
https://bitbucket.org/ https://www.codebasehq.com/ https://www.fogcreek.com/kiln/ https://about.gitlab.com/gitlab-com/ I must admit, I rather like bitbucket, you can get free private repositories with them too.
Thanks for mentioning GitLab, we offer unlimited private repo's and collaborators and an on-premises version too.
Re: GitHub dropped Pygments
#76I honestly don't see a problem here. They decided to change a backend library for a non-essential system in their product. Most services don't ask for permission or make announcements when they make changes like this. The approach seemed to be, if things break, people will report it and we’ll fix it. While this may not be the best approach, the number of languages supported is too high for a person to check each one…
Just switching the library and breaking things at a whim is problematic.
Also, the number of languages may be 316 (including some oddballs like "Unified Parallel C") but that's still a possible number to check for at least for major, obvious breakages. Still, for people that do use Unified Parallel C, adequate highlighting might just be the reason to choose that platform and use it to write your blog in, instead of writing a custom highlighter for prism.js.
Sorry, if you business is code and you decide to support 316 languages, expect people to hold you on that promise.
That said, also: errors happen. But that isn't a reason to give them a pass, just not to put too much weight on such things. It doesn't break the platform at large, but terribly inconveniences some users, and they are very right in being upset, too.
Re: GitHub dropped Pygments
#77I honestly don't see a problem here. They decided to change a backend library for a non-essential system in their product. Most services don't ask for permission or make announcements when they make changes like this. The approach seemed to be, if things break, people will report it and we’ll fix it. While this may not be the best approach, the number of languages supported is too high for a person to check each one…
I beg to differ. Github pushes its code rendering as far as possible, including providing widgets to embed code snippets into you blog. It is also the _main content they display all the time_. That's not "non-essential". Just switching the library and breaking things at a whim is problematic. Also, the number of languages may be 316 (including some oddballs like "Unified Parallel C") but that's still a possible numbe…
What promise did github make?
Re: GitHub dropped Pygments
#78This sort of thing feeds my paranoia about GitHub being a giant single point of failure in the open-source world. I know the argument: Someone, somewhere has a copy of each repo checked out, so we (the nebulous "we") could reconstruct everything from the diaspora of ".git" directories. It just bothers me to think how dependent OSS has become upon GitHub.
Re: GitHub dropped Pygments
#79Earlier quoted context omitted.
I beg to differ. Github pushes its code rendering as far as possible, including providing widgets to embed code snippets into you blog. It is also the _main content they display all the time_. That's not "non-essential". Just switching the library and breaking things at a whim is problematic. Also, the number of languages may be 316 (including some oddballs like "Unified Parallel C") but that's still a possible numbe…
> expect people to hold you on that promise What promise did github make?
Re: GitHub dropped Pygments
#80It's worth noting that even syntax highlighting on common languages like Java is currently messed up on Github. I hope it's fixed eventually, but kinda lame to take something that wasn't broken and break it.