Colin Seymour

> from what I last heard The TextMate engine has not been archived and is still taking bug reports [#6668 (comment)](https://github.com/github-linguist/linguist/issues/6668#issuecomment-1967530241) Correct, it hasn't been archived but AFAIK it is...

I see this [has been confirmed as a bug in VSCode](https://github.com/microsoft/vscode/issues/189940#issuecomment-2323586656) as PrettyLights is matching TextMate 2's behaviour. Closing as there's nothing more to do here.

Do you really want to add support without syntax highlighting? Normally the only reason people add support for a language is to get syntax highlighting on GitHub.

icalendar support is coming in https://github.com/github-linguist/linguist/pull/6940.

> > icalendar support is coming in #6940. > > That grammar is incorrect and also isn't compliant with RFC 5545, it is only iCAL compliant which is a subset...

Sure. https://github.com/search?type=code&q=NOT+is%3Afork+path%3A*.flix+NOT+user%3Aflix I always exclude the language "owner" and other "big hitters" as they often disproportionately affect the results, which is clearly the case here.

I only re-review language popularity when I make a new release which is approx every 3 months. I'll reassess then.

> Would it be best to do that in a separate PR? Yes. Please do it in a new PR. Be quick. I plan to start the next release tomorrow...

> Is there any reason why the license hashes aren't checked as part of Linguist's usual test run? They are, [here](https://github.com/github-linguist/linguist/blob/d190ad88af555bb2ee213aa64205f2b9a97a077d/.github/workflows/ci.yml#L40) but only on pushes. Generally you'd only need to...

> but feel free to create a PR in the meantime. Please don't. The PR will be closed as 11 files is a very long way from meeting requirements and...