-
Notifications
You must be signed in to change notification settings - Fork 591
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rust grammar doesn't produce nice highlighting #502
Comments
I did spend some time learning Rust syntax in the process of porting that tmLanguage to What would be most useful from you as a user of Rust would be examples of English-language rules that we can implement, along with code samples that show a snippet of code we can use to add to the test file. For instance, if identifiers starting with an upper-case letter are always a type, that would be a good rule to add. When it comes down to it, the existing syntax file is a solid base from which to make tweaks from. The syntax test file has a wealth of information to make sure we are preserving information as we move forward. Over the past few months as I've been rewriting many of the syntaxes, we've been slowly standardizing on some scope names. Many of these are in heavy use, however some are not. Unfortunately the My intention is that we are going to continue the rewrite process and start to go back through various syntaxes and standardize the scope names and create official documentation about what scopes should be used where, and what scopes color scheme authors should implement. |
In addition to screenshots, be sure to post the raw code so that it can be copy-pasted for testing purposes. |
Thanks. I might look into the Rust syntax myself and see if I can see an easy way to add the rules I would like. Here's the example snippet from my screenshot: impl FromStr for ScopeStack {
type Err = ParseScopeError;
/// Parses a scope stack from a whitespace separated list of scopes.
fn from_str(s: &str) -> Result<ScopeStack, ParseScopeError> {
let mut scopes = Vec::new();
for name in s.split_whitespace() {
scopes.push(try!(Scope::from_str(name)))
}
Ok(ScopeStack { scopes: scopes })
}
} |
Currently Additionally, The static method calls do need some scopes added, and the instance methods calls need to be tweaked to be consistent with other syntaxes.
|
Right sorry I had forgotten about that, I had already seen that those had annotations, it just slipped my mind while writing the issue. The interesting thing about that snippet though is that the |
Maybe add a |
@trishume maybe you can fix your issues above more easily now that rust-lang/sublime-rust has a |
@jrappen The Rust Enhanced package recent forked the syntax here, so there won't be a ton of differences. I'm hoping to do a little work on the Rust syntax soon to bring it more in line with the evolving scope naming docs. |
Reading my comment from last year (that I totally forgot about), |
This syntax file is generally better for right now, see: sublimehq#502
I observed some other inconsistencies with the scope naming guidelines:
Would pull requests for these be accepted? |
I believe PRs would be accepted, yes - definitely for number 2 anyway. For number one, open a PR and see what discussions arise :) |
I certainly agree with the former. If we're talking about normal function calls of arbitrary identifiers, those should be I'd also like to get highlighting of types for both Rust and Python (which are probably the languages I use the most) based on naming conventions, but I'd like to think that the discussion in #1842 should be resolved first. |
PR #2305 should improve the situation here. |
The built in Rust grammar highlights code less effectively (IMO) than this grammar despite being much more complex and complete.
The reason is that although
Rust.sublime-syntax
assigns scopes to many things that the other grammar doesn't (e.g blocks), it doesn't assign scopes to many of the important things that would actually benefit from highlighting and that themes use.Chief among these is that it doesn't assign a special scope to type names. Even just a rule for matching capitalized identifiers like the
tmLanguage
has would go a long way. As it stands all types except some standard library types get no annotation, and the standard library types get a non-standard annotation used by very few themes.To be fair the C++ syntax has this same issue, but for some reason I don't notice it as much. An argument in favour of highlighting capitalized identifiers in Rust but not C++ is that many C++ projects use lower case type names so it would be inconsistent, whereas all Rust projects I know use capitalized type names.
A rule that highlights capitalized identifiers as
storage.type.rust
would mostly address my complaint, although it would be cool if the grammar could actually parse which identifiers were type names, which might be difficult, but less difficult than it would be for C++.@wbond
The text was updated successfully, but these errors were encountered: