Conversation
Correct me if I'm wrong but Emac and Vim aren't part of the JavaScript (EcmaScript) specs, so why add them here and not in a separate language (inheriting from this package maybe)? |
Good idea. Should we drop support for interpreter directives like |
The That said, I'm not a fan of all the extra fixtures. It should be possible to inline all of those, right? |
Not that I know of. The matching is done when a file is opened, which means the only alternative (that I know of) would be to automatically generate the fixtures when running specs, which would just complicate stuff. |
@50Wliu I'm an idiot, I have no idea why using the grammar's Fixtures removed and remedied. |
What in the world happened to Coffeescript's multiline quotes? |
You referring to the error highlighting in this PR's diff? Yeah, not really sure what's up with that. :S It's perfectly fine in Atom. |
Going to let this sit for a bit longer in case someone spots some issues with the modelines (I've never used Emacs or Vim). Remind me about this in a week please? |
As you wish. |
The existing code doesn't take into account some less obvious cases: #!/bin/env --type=node -*- not-mode: js -*- vim: noexpandtab: ft=javascript
I'm liking this test coverage. |
Heh, I figured it out. The modelines are telling GitHub it's a JavaScript file, so it's using the JS grammar for highlighting. It's doing the same for the other spec-files too. :S Should I prepend a real modeline at the start of each relevant suite to tell Linguist it's really a CoffeeScript file? I mean, the incorrectly-highlighted comments are one thing, but this is really another. |
Yeah, I was laughing at that one. But really, modelines should be at the start of the file, not somewhere random in the middle (and in quotes!)...would that count as a Linguist bug? |
Nope, modelines are often placed at the bottom of a file too, which is the case with all of Vim's syntax files, for example. Linguist reads the first and last five lines when checking for modelines. It's obviously being fooled by the last few Vim modelines, because they're using double-escapes. We could rearrange the lines so the last two aren't within the 5-line radius Linguist uses to scan for modelines, but I think the more sustainable approach is to simply include an extra line at the bottom instead. The scan-scope is, after all, subject to change... especially now that the modeline-patterns have been reinforced to fix the errors which the scope-reduction was intended to ameliorate. |
Self-explanatory; this PR associates JavaScript with any files that contain an Emacs or Vim-style modeline in their header: