OK I think this is ready for review now; I don't think a new heuristic is necessary, since I don't see anything else using the .exp extension that would need to be distinguished from.

I don't think a new heuristic is necessary, since I don't see anything else using the .exp extension that would need to be distinguished from.

I just remembered that .exp is sometimes used in test-suites to contain the expected output of a test run. It's usually paired with a file ending in .act (to denote the actual output from a test), which is compared with the .exp file using the diff(1) utility.

There also appear to be roughly ~203k search results for the .exp extension that doesn't include lines beginning with set or expect. They don't appear to be fixtures for a test-suite either, so this might warrant a more in-depth investation.

Hm, so maybe just a really simple heuristic then? e.g. '^\s*(?:set|expect|proc)\s' or something... (I'm not very good at regexes, so please correct me if I got it wrong)

Hm, so maybe just a really simple heuristic then?

Actually, I was thinking .exp might need to be registered as a generic extension. This is a more esoteric feature of Linguist that's called upon when an extension has widespread usage in unrelated contexts, but none of them have enough adoption individually to merit their own entries in languages.yml. The original use-case was to support Solidity's .sol extension without misclassifying the numerous repositories that used .sol as an abbreviated suffix for "solution".

However, generic extensions have the caveat that an accurate, airtight heuristic is needed, preferably one that matches a pattern or string that's all but guaranteed to appear in the files that we're interested in supporting. The regex ^\s*(?:set|expect|proc)\s will match any line that happens to begin with the word "set", "expect" or "proc", followed by a whitespace character (including a newline). Needless to say, that's very, very error-prone; even if we weren't looking to add a generic extension, I still wouldn't recommend such an open-ended heuristic.

I'm happy to help you with penning the regex, but that assumes there even is a predictable and guaranteed pattern unique to Expect scripts.