Rewrite syntax for Sublime Text 4

[randy3k]

Important: it requires Sublime Text 4. This PR is ready to be merged, but we do want to wait until Sublime Text 4 is publicly released.

The current sublime-syntax has not been maintained for a while and it doesn't cover many of the edge cases because of the complex nature of the Julia syntax. One major difficulty is that Sublime Text 3 is effectively only capable of doing deterministic parsing, so it is almost impossible to differentiate
function call: f(x) and function declaration f(x) = 1 besides using some look ahead or look behind regular expressions. These regular expressions have a somewhat limited ability to captures some of the edge cases.

Some of you may already notice that Sublime Text 4 is coming. In ST 4, we are able to do much better with the branch_point feature.

Before:

After:

(See for example the original syntax failed to correctly identify the third foo).

close #54
close #58
close #60
close #62
close #72
close #73
close #77
close #78
close #79
close #81

[musm]

Sublime Text 4 ? Did you mean Sublime Text 3?

[randy3k]

No. It’s Sublime Text 4. The alpha release was announced in Sublime Text discord channel.

[jwortmann]

Was it intended to remove the additional variable.macro scope? I think it is nice to give users the option to highlight macros differently from function calls.
Same in L121.

[randy3k]

It was not intended. I agree that it’s a good idea to have those scopes back.

[jwortmann]

With the changes from your last commit (variable.macro.julia support.function.julia) it would only work if the color scheme targets this full scope, but a rule for only variable.macro will be overriden by a support or support.function rule in the scheme. Therefore better change the order to support.function.julia variable.macro.julia like it was before, so that it will still work if someone used only variable.macro?

[randy3k]

I was trying to match the scoping convention of python's @property decorator.

Another possibility is to remove support.function.julia because technically the most macros are not built-in.

[jwortmann]

I would say Julia macros are more like preprocessor directives in C/C++/C#, than Python's @... decorators or for example @override annotations in Java. To remove support.function.julia would be an option, but if the color scheme doesn't target variable or variable.macro they wouldn't be colored at all. In fact that would be the case for e.g. the Monokai and Mariana scheme. So I think to use support.function.julia variable.macro.julia would be the better option.

Another alternative could be to use support.macro.julia for all built-in macros (list) and variable.macro.julia for the rest. On the other hand this would mean that common macros from imported packages would only get variable.macro then as well.

[jwortmann]

After reading a bit more about Python decorators, I recognized that they are more powerful than I initially thought. Howerver, for a non-predefined decorator like @my_decorator, the Python syntax uses only variable.annotation.python meta.generic-name.python. So I would recommend to either remove the support scope for Julia macros that are not built-in, or change the scope order to how it was before.

[randy3k]

I have removed the scope support.function for non builtin macros.

[jwortmann]

Alright, I think that is a good solution. The only thing that seems to be missed now is @..

-    - match: '(@)({{base_macros}})'
+    - match: '(@)({{base_macros}}|\.)'