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.
GitHub dropped Pygments
121–130 of 133 posts
Re: GitHub dropped Pygments
#122Earlier 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…
Re: GitHub dropped Pygments
#123Re: GitHub dropped Pygments
#124This 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.
Re: GitHub dropped Pygments
#125Earlier 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.
Re: GitHub dropped Pygments
#126Earlier 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 "
Re: GitHub dropped Pygments
#127Earlier 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.
Re: GitHub dropped Pygments
#128Earlier 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.
Re: GitHub dropped Pygments
#129Earlier 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.
I'm not sure you understand the network effect and how that ties into Github's business.
Re: GitHub dropped Pygments
#130Earlier 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…
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.