Skip to content
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

Ruby syntax coloring missing for suggested fail/raise statments #99

Open
FichteFoll opened this issue Feb 4, 2015 · 2 comments
Open

Comments

@FichteFoll
Copy link
Contributor

From @jptalton on February 4, 2015 16:40

OS: OSX, ST: Stable 3065

ruby suggests using:

fail Exception, 'msg'  # no good :(

over:

  fail Exception.new('msg') # good, but not prefered :(

however, when doing so, the syntax highlighter for ruby no longer detects the single word "Exception" as a Class References. This also happens in a few other misc. places, but this one seems to catch my eye the most.

Copied from original issue: sublimehq/sublime_text#665

@aziz
Copy link

aziz commented Jul 1, 2015

I believe this is not a bug.
the Exception in fail Exception, 'msg' # no good :( has a variable.other.constant.ruby scope which is all that can be inferred from a capitalized name in Ruby.
But when you call .new(something) on it you give the syntax parser more clues to infer that it's a class and hence the support.class.ruby scope.

@FichteFoll
Copy link
Contributor Author

According to https://manual.macromates.com/en/language_grammars#naming_conventions,

support — things provided by a framework or library should be below support.

the support scope is only meant for names provided by the language, not custom ones. Thus it should only be applied to default classes or exceptions and not to custom exceptions determined by casing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants