[abhinavg]

I 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 manually. Generally, I imagine they wouldn't expect a change like this to break anything significant.

[people] use it as a portfolio. [..] To suddenly doink the appearance of people’s portfolios is unfortunate.

It is very unlikely that syntax highlighting errors in GitHub will affect someone's chances of getting a job.

Sure, this switch could cause some issues but they don't seem to be severe enough to kick up a fuss over.

[Argorak]

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

[tomcorrigan]

> expect people to hold you on that promise

What promise did github make?

[Argorak]

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

[resetti]

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.

[Argorak]

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.

[scott_s]

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

[rofl1234]

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.

[darkarmani]

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

[conradev]

One other thing to note is that it's not just syntax highlighting, it's also recognizing the language a given repository is written in.

Some of my repositories that use Logos[1] are now incorrectly classified as a combination of Ruby and Scala[2].

[1] http://iphonedevwiki.net/index.php/Logos

[2] https://github.com/conradev/Tweaks

[lelandbatey]

Yep. And now Github thinks my Makefile is JavaScript: https://github.com/lelandbatey/link_grab

[lbearl]

It comes up as an "Executable File" for me. Guess they are making tweaks still.

[sitkack]

Sounds like amateur hour.

[greghendershott]

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 reasonable choice.

The situation now is that they've replaced a library that had been handling highlighting thoroughly, with a variety of text-editor lexers that mostly are not. People like me who already contributed to Pygments, aren't feeling motivated to do this all over again for no good reason. So it seems likely the lexers will remain poor for quite a long time. Which is unfortunate.

Finally, at the time I wrote my blog post, I was speculating about the motivation because GitHub hadn't explained why, yet. Someone later did explain ("because speed") in the issue thread.

[res0nat0r]

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.

[soegaard]

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.

[alextgordon]

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 static syntax highlighting.

[chipotle_coyote]

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

[alextgordon]

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.

[Tombone5]

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.

[Demiurge]

> It is very unlikely that syntax highlighting errors in GitHub will affect someone's chances of getting a job.

And if it does, the problem lies not with the syntax highlighting, not even close...

[muyuu]

Also, not a great idea to rely on some "cloud" 3rd party service to host your portfolio IMO - at least not exclusively. Maybe I'm old-fashioned.

That said, I don't think anyone will bin a candidate because Github didn't highlight his or her code properly.

[regularfry]

It's not that people necessarily choose to host portfolios on github, but more that employers will treat whatever's on there under your name as a portfolio regardless.