Improve elixir grammar

Hi! I was wondering if you have plans to improve the current elixir grammar.

I’m asking because I was recently extending some elixir color schemes and noticed that some tokens are missing or don’t have a distinction from others. For instance, both key: (parameter) and :key (atom) are defined as source.elixir > constant.other.symbol.elixir which prevents me from highlighting only atoms.

I was looking for solutions and saw that the ruby extension has a little bit more definitions: https://github.com/rubyide/vscode-ruby/blob/master/packages/vscode-ruby/syntaxes/ruby.cson.json (if you search the page for “hashkey” you’ll see some good examples).

[CaiqueMitsuoka]

Hey @thiagomajesk nice to see you looking into improve the function names detection on the elixir grammar.

Let me see if I can help you on anything.

First of all I made de PR adding it quite recently PR#15, take some time to look into it.

There are some open conversation yet in the 2 PRs that did to the grammar for sublime which Valim takes care of. I recommend you look into that too. elixir-editors/elixir-tmbundle PR#179 elixir-editors/elixir-tmbundle PR#181

About calling the definition and the actual call the same scope, that was a decision that I took base on the TextMate grammar manual but people are asking for a differentiation and I think its fair enough to give people what they want, I will start working on it, and will take your thoughts in consideration and ask for you review 🙇 .

The case of the function calls without parenthesis is that they are ambiguous with plain variables. Only when a the call has a module that it is explicitly a function call(e.g Module.call) So why support all other types of call if the implicit stays out of support? Because the ideia is that it will be remove and we don’t want to encourage the use of it. The compiler throws a warning and the formatter adds the parenthesis by default.

Your examples Module.call(%Task{}) and call(%Task{}) works fine here. But is actually it falls into other rule, that was included together.

{
  "match": "\\b[a-z_]\\w*[!?]?(?=\\s*?\\.?\\s*?\\()",
  "name": "entity.name.function.elixir"
}

[axelson]

Partially solved in #40. As mentioned at https://github.com/elixir-lsp/vscode-elixir-ls/pull/40#issuecomment-589199897 this issue is rather broad and would be better tackled with individual issues/PR’s.

Based on that, I guess it wouldn’t hurt to include a “namespace” scope bellow the meta.module.elixir. This way the current coloring will be the default if you don’t specify a config for the namespace scope (it’s basically the user’s choice to use it or not with a sane behavior by default).

I’m open to adding a syntax definition that would assist with this as long as it isn’t colored by default in most themes, although I may want a different name like module-prefix

A better example would be comparing def fun(x), do: x and [key: “hello”] == [{:key, “hello”}]. Currently is not possible to highlight only atoms. In the previous example, both do: and key: or :key would be colored the same because they are both a constant.other.symbol.elixir. So I guess having this definition for atoms would be nice to optionally extend a color scheme and create this distinction (even though in your example they are conceptually the same).

do: and :key are both atoms, since def is just a macro and actually uses keyword list syntax under the hood: https://elixir-lang.org/getting-started/case-cond-and-if.html#doend-blocks

Potentially an additional scope could be added for do:, but by default it should be treated as an atom.