GrammarKit is a plugin by JetBrains for creating custom language plugins
for JetBrains IDEs (such as IntelliJ, RubyMine, CLion and more). It
defines a BNF parser language which can be used to generate a parser in
Java, and it also integrates JFLex for generating a lexer in Java.
Both of these generated Java files can be recognised by a comment on the
first line of the file, and so classifying them as generated is trivial.
TLDR: This greatly increases the flexibility of vim modeline detection
to manually set the language of a file.
In vim there are two forms of modelines:
[text]{white}{vi:|vim:|ex:}[white]{options}
examples: 'vim: syntax=perl', 'ex: filetype=ruby'
-and-
[text]{white}{vi:|vim:|Vim:|ex:}[white]se[t] {options}:[text]
examples: 'vim set syntax=perl:', 'Vim: se ft=ruby:'
As you can see, there are many combinations. These changes should allow
most combinations to be used. The two most important additions are the
use of the keyword 'syntax', as well as the addition of the first form
(you now no longer need to use the keyword 'set' with a colon at the end).
The use of first form with 'syntax' is very, very common across GitHub:
https://github.com/search?l=ruby&q=vim%3A+syntax%3D&ref=searchresults&type=Code&utf8=%E2%9C%93
When using syntax extensions in stable or beta Rust channels using the syntex package, it is common to use the file extension .rs.in for the source file, and .rs for the generated file.
Since Octave is a clone of Matlab, the syntax is exactly the same
and hence it is desirable for highlighting to be exactly the same
as well.
Adding octave as an alias for Matlab will trivially provide support
for highlighting Octave code, and will ensure the two languages
always use the same syntax highlighting rules.
Linguist currently uses the presence of "move" commands to differentiate
a GAS file from Groff. This is problematic with MAXScript, with includes
a built-in function of that name. Furthermore, because of the language's
exhaustive vocabulary, case insensitive nature and flexible syntax, it's
difficult to impose rigid criteria on classifying it.
This commit modifies the heuristic to assume the following flow:
1. If a line contains ".include" or ".global"/".globl" which doesn't
follow a non-whitespace character, assume GAS.
2. Otherwise, if the line starts with a command like ".LG7E0" with a
possible string of whitespace before it, assume it's also GAS.
UNLESS either of the following conditions are true:
2a. The token is enclosed by a string or /* multiline comment */
2b. The previous line ends with a backslash to denote a statement
broken between lines, with possible whitespace and/or comment
sequences between the backslash and the actual newline.
3. If neither of the above are met, assume the file is MAXScript.
This approach may appear overly-inclusive, but given real-world usage of
MAXScript includes writing brief files with few distinguishing keywords,
it's reasonable to permit this leniency.
Rake's tests are failing because #0AA is too similar to the colour being
used by another language (Dart: #00B4AB). This commit increases contrast
enough to satisfy the build (with 00A6A6 being the closest shade allowed
by the current colour threshold).
See also: github/linguist@3c96f9e
