Ok to use grammar.cson for just file assoc…?


I’m making this language package for Scala with a server backend called Ensime. I depend a lot on filtering so I just act upon scala files with the scope name “source.scala”. When deactivating it I just realized that I was depending on the language-scala package which made the mapping from .scala and .sbt to source.scala in it’s grammar file. To remove this hard dependency, can I just add a grammar/scala.cson like:

'scopeName': 'source.scala'
'name': 'Scala'
'fileTypes': [

with nothing else or will this make some kind of conflict? (it seems to work)

Or is there any more idiomatic way to achieve the file-ending to scope-name mapping?


Have you checked out what happens if you have a source.scala and the regular language-scala package is already installed?


Ooh, I take it back, it does not work. The language-scala (syntax highlighting) package does not trigger when I add that to my own package.

Any workaround? I want to use a correct way to check that I’m only doing stuff on scala files and “source.scala” scope should be used for just this, right? But it’s not very nice that I need to hard-depend on a separate syntax highlighting package, in particular since I’m intending to do semantical highlighting.


Sounds like you’re trying to do the same kind of thing as is mentioned here?


Well, it’s not really that I’m trying to do. I just want filename to scope mapping that doesn’t interfere. *.scala -> source.scala.


If you’re also going to do syntax highlighting, wouldn’t that mean that the two packages would interfere anyway?


My idea is to typically have the language-scala package doing syntax highlighting statically and super-fast while my package atom-ensime uses the backend server to enrich with semantic highlighting asynchronously (also under a settings flag). Just a reference what I’m talking about:


My idea is to just make my plugin add more specific css rules with markers+decorations when semantic highlighting is turned on.

I could of course just copy the whole language-scala plugin as part of my plugin and this would work fine for now, but it would be a lot better not to.


Maybe I can depend on

and add a line like the this to my activation:

but it feels a bit… I don’t know. Not right?


But then again, with that approach I have this whole “depending on other atom packages” problem instead, right: Depending on Other Packages


Ok, I see. That’s pretty awesome :smile:

In my opinion it makes more sense to depend on the language-scala package than the atom-file-types package. Another option would be to check if there’s already a grammar registered for the scope, and otherwise load your (empty) grammar. Something like this

unless atom.grammars.grammarForScopeName 'source.scala'
  atom.grammars.loadGrammar 'scala-grammar.cson'


Awesome, that seems like the snippet I was looking for!

I just got to defer it 'til after the all packages are loaded, right? I think the conflict I had now was that my package was loaded before language-scala, but If I wait until activation (which is a manual thing in my package) I should be fine…

Just one more question. The built in assocs I get when typing:


are those all created by grammar-files or is there some secret built in way to setup these that are nicer than a grammar file?


You can use this snippet to wait for just the language-scala package to be activated:

  atom.packages.isPackageLoaded('language-scala') && atom.activatePackage('language-scala')
).then (languageScalaPkg) ->
  if languageScalaPkg
    # language-scala is loaded and activated
    # language-scala is not loaded

However, I think waiting for all packages to be activated is a better approach (just thought this is a nice snippet :smile:), because it also supports other packages adding a grammar for source.scala.

But I think you don’t really have to wait for the grammar-providing package to be activated at all, because loading a grammar overwrites previous grammars for that scope (I got this from reading the source code). So when your grammar loads first, it will be overwritten by the one provided by language-scala (or other), and when your package loads last, you check if the grammar already exists. Note that you shouldn’t put the grammar file in the grammars directory, because then Atom will load it anyway, and it might choose the wrong one…

I don’t understand your second question. Could you elaborate?


Thanks, awesome!

My last question is just this: I’m not really adding anything related to grammars, I just want to associate files *.scala to the scope “source.scala”. I’m thinking there might be some programmatic way to do just that without “hacking” with an empty grammar.


As far as my understanding of Atom goes, it’s actually the grammar that defines the scope for the editor, so I don’t think there’s a way to do what you’re describing. Then again, I could be wrong on this. Maybe someone with more knowledge can explain?


Thanks! I got it working with your snippet. However, I was a bit optimistic on what could be achieved with markers+decorations. I thought I could style the text itself, but I understand now that “highlights” only supports blocks. I will try to use the squiggly underline thing I found elsewhere and leave syntax highlighting for now.