Live data from Hacker News

GitHub dropped Pygments

greghendershott.com

121–130 of 133 posts

Re: GitHub dropped Pygments

#121
post #55

Earlier quoted context omitted.

Thanks for mentioning GitLab, we offer unlimited private repo's and collaborators and an on-premises version too.

We've been happily using GitLab for months now, can't recommend it highly enough. If there was an open source bug tracking/ticket app that played nicely with it I'd switch all of our teams over to it sooner rather than later.

It has it's own issue tracking, as well as wikies and everything else github offers.

Re: GitHub dropped Pygments

#122

Earlier quoted context omitted.

Github now uses the lexer framework from TextMate and SublimeText. If your language community happens to use those editors, then you are fine. For Racket 99% uses either DrRacket or Emacs. This implies that the lexer deployed is very rudimentary. Any pointers besides the TextMate documentation for writing lexers are welcome.

Which is sad, because the TextMate lexer design is really really awful . Mostly undocumented. Lots of oniguruma-specific regexes used in the syntaxes. Inefficient beyond comprehension. For instance, TM syntaxes can legally have recursion loops in them, which TextMate will cut so that the app doesn't spin into infinite recursion. But the precise way that it does this is a mystery. The pygments design is better for sta…

Point of curiosity: Chocolat is compatible with TextMate syntax files, IIRC. Was going with TM syntax purely a pragmatic choice? Is it not so bad for in-editor syntax highlighting? It seems like virtually every text editor that hit the market -- or whatever one would say for free programs like Atom -- after TextMate adapted TM syntax files. (While BBEdit's comparative inflexibility in syntax highlighting, even the new BBEdit 11 format, irks me, it's hard not to notice that it's a much better performer on giant files.)

Re: GitHub dropped Pygments

#124

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.

Would a P2P version of GitHub make sense? Each outward-facing local repo would provide a GitHub-like interface for browsing code, submitting PRs etc., and would in addition route repo search requests to neighboring repos using something like a Gnutella protocol.

Lightweight but great for LANs like the Rails Camp that it was built for: https://github.com/toolmantim/bananajour

Re: GitHub dropped Pygments

#125
post #46

Earlier quoted context omitted.

> HN has cultural norms for downvoting Those cultural norms are not written into any of the faqs or guidelines and they only exist within a subset of the users of the site. I don't know why you were downvoted so heavily! I would have thought that a few downvotes would have been enough.

"Those cultural norms are not written into any of the faqs or guidelines " Cultural norms usually aren't, that's why they're culture.

But those cultural norms are also only strong in a small subset of users. Plenty of people vote to agree or disagree, and this was acknowledged by pg. "Don't down-vote to disagree" is something brought over from Reddit and there is some strong resistance to it in some long term users (here longer than six years).

Re: GitHub dropped Pygments

#126

Earlier quoted context omitted.

I don't recall that ever being the case. And I've used SourceForge since 2005.

I remember it being the case in 2007/2008. This is the closest thing I could find to a citation. http://www.codeproject.com/Articles/4439/Getting-started-wit... "To create a new project you simply register at SourceForge and then submit a new project request. Most projects are approved immediately, and you'll typically get an email notifying you of the approval in ~ 24 hours "

It might have happened between when I'd originally registered and the present. It does make sense as SourceForge was providing free FTP uploads for binaries at the time and the automated tools to handle abuse were pretty poor. Lots of folks were looking to abuse it for bandwidth and malware distribution. The tools are better now, which is one reason Github finally added binary releases last year.

Re: GitHub dropped Pygments

#127

Earlier quoted context omitted.

We've been happily using GitLab for months now, can't recommend it highly enough. If there was an open source bug tracking/ticket app that played nicely with it I'd switch all of our teams over to it sooner rather than later.

It has it's own issue tracking, as well as wikies and everything else github offers.

It does but GitLabs ticket capabilities are very, very basic.

Re: GitHub dropped Pygments

#128
post #46

Earlier quoted context omitted.

That is true if all downvoters are independent. Keep in mind that HN has cultural norms for downvoting, it is explicitly not for "silencing" opinions.

> HN has cultural norms for downvoting Those cultural norms are not written into any of the faqs or guidelines and they only exist within a subset of the users of the site. I don't know why you were downvoted so heavily! I would have thought that a few downvotes would have been enough.

Complaining about downvotes is one of the easiest ways to accumulate them.

Re: GitHub dropped Pygments

#129
post #98
post #79

Earlier quoted context omitted.

The promise any service makes. To solve my problems and to work _as a service_ for me.

That's neither how promises nor the laws around them work. GitHub owes you nothing except what was explicitly spelled out when you signed up. Half the difficulty of running a business comes from customers with a sense of entitlement not understanding this.

> Half the difficulty of running a business comes from customers with a sense of entitlement not understanding this.

I'm not sure you understand the network effect and how that ties into Github's business.

Re: GitHub dropped Pygments

#130

Earlier quoted context omitted.

Which is sad, because the TextMate lexer design is really really awful . Mostly undocumented. Lots of oniguruma-specific regexes used in the syntaxes. Inefficient beyond comprehension. For instance, TM syntaxes can legally have recursion loops in them, which TextMate will cut so that the app doesn't spin into infinite recursion. But the precise way that it does this is a mystery. The pygments design is better for sta…

Point of curiosity: Chocolat is compatible with TextMate syntax files, IIRC. Was going with TM syntax purely a pragmatic choice? Is it not so bad for in-editor syntax highlighting? It seems like virtually every text editor that hit the market -- or whatever one would say for free programs like Atom -- after TextMate adapted TM syntax files. (While BBEdit's comparative inflexibility in syntax highlighting, even the ne…

There are two types of syntax highlighting: static and dynamic. Static is like GitHub/Gist/Pastebin, dynamic is like Atom/TM/Sublime. Static highlights the file straight through, and the result can be cached indefinitely. Dynamic highlighting in a text editor parses as little of the document as is theoretically possible, in response to an insertion, deletion or replacement.

For static there's tons of choices. Pygments, prism.js, GeSHi for PHP, etc. Any idiot can write a static highlighting system. But none of these can be used in-editor.

For dynamic highlighting, there is only one game in town and that's tmbundles. Only TextMate has support for the 100s of languages in existence, including the new ones that pop up each day.

I would love to replace tmbundles. I know just how to implement it. But the problem is, who is going to write all the long-tail language support? VHDL, Pascal, GAP, AtScript, Julia, ...

- - -

Interesting you mention BBEdit. I have a test file I call "the behemoth" which consists of a python file with 32000 copies of this:

    """ """
The challenge is to insert """ at the top of the file and see how the text editor cries in pain. It's torture to a syntax highlighter.

To pass, the editor must

1. Load the file quickly

2. Have smooth scrolling inside the file, even after making the change.

3. Color the quotes properly through the end of the file, before and after.

To my knowledge BBEdit is the only editor to pass the test. Emacs is a good 2nd place.

Post reply on HN