Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GitHub dropped Pygments

greghendershott.com

Post reply on HN
Print view View original

101–110 of 133 posts

Re: GitHub dropped Pygments

#101

Post by jessaustin »

smoe wrote: post #54
Twirrim wrote: post #52

Earlier 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.

I can really recommend the open source gitlab for self hosting repos. I have been running it on a ec2 micro instance for 5-10 people over years without a single problem. https://github.com/gitlabhq/gitlabhq

Now there is a FOSS project one might have expected to dogfood. Nothing beats free... b^)

Re: GitHub dropped Pygments

#102

Post by Tombone5 »

res0nat0r wrote: post #100
greghendershott wrote: post #91

Earlier quoted context omitted.

I didn't expect my blog post to be on the front page of HN. Here's a TL;DR summary: For many languages this is a significant and distracting degradation in the presentation. I could understand GitHub removing highlighting completely because they feel speed is the overriding priority. That would be even faster than what they're doing now. Languages would look "plain" instead of "wrong". Not my first choice, but a reas…

Are the majority of languages now broken, or just a small niche subset that don't see much use vs. ruby, python, etc? If a few minor languages hardly anyone uses as compared to the whole site might need some fixing, this still seems like a win from Github's side of things since per the graph the change did in fact significantly improve render times.

The rule of thumb is that most languages are rarely used (since there are a finite number of users), so if you support only the most used languages you necessarily drop support for most languages.

Then depending on exactly how popular a language must be to be supported you could end up breaking language support for quite a lot of them.

Re: GitHub dropped Pygments

#103

Post by Argorak »

resetti wrote: post #98
Argorak wrote: 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.

The other half being providing a service they find worthwhile that doesn't change at every whim.

Taken to the other extreme, a constantly breaking Github doesn't have any value proposition.

Promises are not always explicit and not at all related to laws.

The next Transformers being something to look forward to is a promise, but that doesn't mean not liking it is in any way wrong or that I could sue someone for it. I can choose to leave the movie and never go see one again. The producers of Transformers certainly owe me nothing, but they also cannot tell me how to feel about their handling of the material.

Github promises the most awesome code hosting around. That's a very different thing for many people. And to some people you can live up to the promise, to some people you cannot and it's perfectly fine for those to feel let down. Calling all those people "entitled" is, quite frankly, insulting.

As I said: putting this like it is the end of the world is overreaching, but it is a valid complaint and a valid sentiment. Saying that this is the most important thing on Github, because it happens to be specific your problem is entitlement.

Finally, it isn't true that you are only bound by spelled out things. The law many people cite so often has the concept of Good Faith: http://en.wikipedia.org/wiki/Good_faith_%28law%29 and similar fun things that extend beyond that. So Github _does_ owe me beyond their ToS. (I appreciate that this is probably not a case covered by this)

It's a common sentiment in these circles that only the rules written on the contract are the ones that count, while nothing can be further from the truth, widely varying from legislation to legislation.

Re: GitHub dropped Pygments

#104

Post by raverbashing »

shurcooL wrote: post #47
Demiurge wrote: post #15

Earlier quoted context omitted.

I don't think it's paranoia. I think it factually is a single point of failure, which is a bad thing(tm). And GMail is a single point of failure for my (and my companies) e-mail, and that bothers me too, despite the fact that I'm not doing anything about it :)

This planet is also a single point of failure. If a meteor strikes, all our code will be lost.

At one project I worked, someone created a bug "system will stop working with the end of the world on " (yes, it was a joke)

Fortunately the bug was closed.

Re: GitHub dropped Pygments

#105

Post by atomaka »

jessaustin wrote: post #101
smoe wrote: post #54

Earlier quoted context omitted.

I can really recommend the open source gitlab for self hosting repos. I have been running it on a ec2 micro instance for 5-10 people over years without a single problem. https://github.com/gitlabhq/gitlabhq

Now there is a FOSS project one might have expected to dogfood. Nothing beats free... b^)

They do: https://gitlab.com/gitlab-org/gitlab-ce/. They maintain a Github mirror to allow for easier contribution. Github is more than just a version control software; it's a community.

Re: GitHub dropped Pygments

#106

Post by JohnTHaller »

mcphage wrote: post #96
JohnTHaller wrote: post #93

Earlier quoted context omitted.

There's also SourceForge, which hosts SVN, Git, Hg, etc and is the largest host of FLOSS applications (Git is the largest host of FLOSS components and web code).

I'm not sure if it's still the case, but SourceForge used to have an approval process to get a new project / repo set up, which defeats a lot of the utility of GitHub for being able to store whatever projects you want to toss up there.

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

Re: GitHub dropped Pygments

#107

Post by rofl1234 »

resetti wrote: post #98
Argorak wrote: 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.

nobody's talking about legal contracts. the issue is of good will. the promise github has made is they would provide all kinds of hosting (git, gitsts, pages, whatnot). people move from other solutions to github because the github's promise (again, not a legal contract) is "we're better".

the other half the difficulty of running a business comes from making tacit promises and then acting annoyed that the other side holds you to them.

Re: GitHub dropped Pygments

#108

Post by scott_s »

Argorak wrote: post #103
resetti wrote: post #98

Earlier quoted context omitted.

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.

The other half being providing a service they find worthwhile that doesn't change at every whim. Taken to the other extreme, a constantly breaking Github doesn't have any value proposition. Promises are not always explicit and not at all related to laws. The next Transformers being something to look forward to is a promise, but that doesn't mean not liking it is in any way wrong or that I could sue someone for it. I…

Agreed. A business relationship is more like personal relationships than I think some technical people think. Pointing at the contract is a failure condition.

Re: GitHub dropped Pygments

#109

Post by soegaard »

res0nat0r wrote: post #100
greghendershott wrote: post #91

Earlier quoted context omitted.

I didn't expect my blog post to be on the front page of HN. Here's a TL;DR summary: For many languages this is a significant and distracting degradation in the presentation. I could understand GitHub removing highlighting completely because they feel speed is the overriding priority. That would be even faster than what they're doing now. Languages would look "plain" instead of "wrong". Not my first choice, but a reas…

Are the majority of languages now broken, or just a small niche subset that don't see much use vs. ruby, python, etc? If a few minor languages hardly anyone uses as compared to the whole site might need some fixing, this still seems like a win from Github's side of things since per the graph the change did in fact significantly improve render times.

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.

Re: GitHub dropped Pygments

#110

Post by jessaustin »

Matthias247 wrote: post #74

I don't know about pygments but my experience with writing a custom highlighter for Sublime Text (aka Textmate, Atom and what Github seems to use now) was that it is not really a good and reliable system for highlighting. It 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…

I really would have expected a highlighter written in Coffeescript to do a better job highlighting Coffeescript.

https://github.com/atom/highlights#using-in-code

(Generic identifier looks the same as class identifier looks the same as a property in an object literal looks the same as a string. I guess maybe orange is just the color used left of an equal or colon, but in that case the string color should be different.)

Post reply on HN