GitHub dropped Pygments
greghendershott.com
GitHub dropped Pygments
1–10 of 133 posts
Re: GitHub dropped Pygments
#2It is still difficult for me to express my opinion of this move without simply resorting to strings of profanity. Frankly, I suspect Atom has more to do with it than anything.
Re: GitHub dropped Pygments
#3It is still difficult for me to express my opinion of this move without simply resorting to strings of profanity. Frankly, I suspect Atom has more to do with it than anything.
Why is Atom more strategically important to Github than existing developers? Is there an economic belief that Atom will reach some larger base of untapped developers who don't know how to use other editors?
If a vendor cannot be trusted to host your content without regression, why would you trust that vendor to supply your mission-critical editor?
Re: GitHub dropped Pygments
#4I assume the new syntax highlighter is way, way faster than pygments. It's written in C++ rather than Python. (Atom uses the same grammar format, but a Node implementation.)
Re: GitHub dropped Pygments
#5I assume the new syntax highlighter is way, way faster than pygments. It's written in C++ rather than Python. (Atom uses the same grammar format, but a Node implementation.)
Why not give existing users the choice of migration and timing?
Re: GitHub dropped Pygments
#6I assume the new syntax highlighter is way, way faster than pygments. It's written in C++ rather than Python. (Atom uses the same grammar format, but a Node implementation.)
Your assumption is correct. The blog post links to an issue in which an official statement (and a graph) can be found:
https://github.com/github/linguist/issues/1717#issuecomment-...
>By using TextMate grammars we also get some nice features like highlighting SQL inside Ruby heredocs. But the main motivation was improving performance.
Re: GitHub dropped Pygments
#7I assume the new syntax highlighter is way, way faster than pygments. It's written in C++ rather than Python. (Atom uses the same grammar format, but a Node implementation.)
Why not give existing users the choice of migration and timing?
Giving users the choice of "slow" in a webapp means that both hardware and software deployment/management/purchasing is greatly complicated.
Re: GitHub dropped Pygments
#8This 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
#9Earlier quoted context omitted.
Why not give existing users the choice of migration and timing?
Giving users the choice of "slow" in a webapp means that both hardware and software deployment/management/purchasing is greatly complicated.
Existing users are being served by existing hardware and software. It wasn't "slow" for them before.
Many companies provide existing users with advance notice of technology migration, so they can plan and adapt.
Why is advance customer notice incompatible with Github ops planning?
Re: GitHub dropped Pygments
#10It is still difficult for me to express my opinion of this move without simply resorting to strings of profanity. Frankly, I suspect Atom has more to do with it than anything.
[deleted]