Emi

@nathany @gtrevg not a fork at all. It was written from the ground up and has different goals than gopkg.in (they're independent projects). see [here](http://azul3d.org/semver) for more details on that.

Sent https://github.com/guillermooo/dart-sublime-bundle/pull/585

@rsc closed the most recent CL for this with the comment: > I really don't think we should do any of this. This is much less understandable than the current...

@rsc that is because someone linked to it in a Markdown link / comment: https://github.com/Shopify/themekit/issues/102#issuecomment-169756401 What can be done here? A better implementation? It's not clear to me.

FWIW I like the idea of making this more clear quite a lot. As for the actual implementation, it's hard for me to say. But I would lean towards panics...

FYI, I have worked around this with https://github.com/gopherjs/vecty/commit/10e09b143553c2e498c08a6abcb3d9212ce61ff8

I'll try to gather some evidence & reproduction cases, but more recently I've seen what appears to be Syntect getting stuck entirely somewhere in the state machine (i.e. never completing...

Over at Sourcegraph we've been using Syntect for several years and I can say the following (but I am not a lawyer): - [MIT licensed](https://github.com/trishume/syntect/blob/master/LICENSE.txt): Syntect itself, as in everything...

Just saw this. I am indeed also interested in how we could make adding more language syntaxes a more official process (there was some prior discussion of this at https://github.com/sourcegraph/syntect_server/issues/3...

Question: Would this mean having the ability to operate without access to hardware-level virtualization, too? Or is that out of scope for this issue?