julia highlight is not coherent with other language syntaxes about julia-sublime HOT 12 CLOSED

Thanks! However, something is not right... Are you not using the latest version?

• Variables works fine
  
• Function declaration works fine
  
  
• Function calls; currently all function calls have support.function
  
  see the comment https://github.com/JuliaEditorSupport/Julia-sublime/blob/master/Julia.sublime-syntax#L138.
  Furthermore, arguments have no particular scope, I agree this should be fixed.
  

I'm open for discussion regarding support.function, I have function calls highlighted for all languages in my color scheme. I'm okay with removing support.function for all function calls. However, I'd need a list of what functions calls to give the scope support.function. (Personally I think it is weird to distinguish between some function calls and others, but that's personal opinion and I disregard that. Consistency across languages is important.)

I realize, perhaps you are using an old version of sublime text, from the readme:

Sublime Text 3 Build 3103 or later will use Julia.sublime-syntax which provides superior highlighting. For backward compatibility Julia.tmLanguage acts as fallback.

If you could be a bit more specific, I can implement a fix more easily. Ideally you could write some failing tests in https://github.com/JuliaEditorSupport/Julia-sublime/blob/master/syntax_test_julia.jl.

from julia-sublime.

Stupid me. I forgot to pull the latest commits and it does fix some of the issues.
However, for the regular variables, they should not be matched, even for variable.other. At least it is how python and r behave. See how the variable a is colored in the updated screenshot. (My color scheme highlights the scope variable.other)

Check the updated list above.

from julia-sublime.

I have function calls highlighted for all languages in my color scheme

If you want to the same coloring for both supported functions and general functions, you just need to edit your color scheme and modify the color for the scope variable.function. However, it will affect all other languages such as python and r.

from julia-sublime.

1. We should really distinguish between setting scopes (determined by this package) and how scopes are highlighted (determined by color schemes). However, it is reasonable to make sure that the default color scheme looks good.

2. Regarding variable.other, there is already an inconsistency across default languages here, javascript adds this scope:
   
   The default color schemes does nothing with variable.other and I think it is good to add this scope, so that plugins and color schemes can track variables. You probably want to look over your particular color scheme.

3. regular function call should be variable.function only and the arguments should be meta.function-call.arguments variable.parameter

   Bold part yes, I have fixed this now, in commit cc2b8de, so that only built-in functions have support.function and all functions have variable.function, function calls have meta.function-call and function call arguments have meta.function-call.arguments. However, note that not all languages add meta.function-call.arguments to function call arguments, JavaScript does not add this scope:
   

   regular function call should be variable.function only and the arguments should be meta.function-call.arguments variable.parameter

   Bold part no? variable.parameter is for arguments in function declaration only. For example, Python has these scopes
   

With this I consider all items in your list checked. Do you agree?

from julia-sublime.

I guess we need to be more specific, I meant the variable name but not the value of the variable. Python uses variable.parameter for the variable name.

foo(x = y)
#   ^ variable.parameter

from julia-sublime.

Though you mention that Javascript also uses variable.other, a lot of Julia users are more familiar to Python then JS. It seems that it makes sense to follow the convention of Python/C/Ruby, etc.

Besides, if one's color scheme highlights variable.other, the emojis are also highlighted and it is less satifactory.

WIth that said, I respect your any decision on this issue.

from julia-sublime.

I mostly agree, will look into this more, but first, when is variable.other supposed to be used, if not for plain variables? Why do you highlight variable.other?

from julia-sublime.

From here, I have gathered the list of usages,

• Regular variables

  • ASP, C#, GO, JavaScript, PHP

• Special variables

  • C++: initialization list
  • Lisp: global variables
  • Python: placeholder variable "%s"
  • Ruby: constant variable
  • YAML

All other syntaxes either do not use variable.other or those are the syntaxes which I don't have much exposure.

I am using a variation of https://github.com/jonschlinkert/sublime-monokai-extended which highlights variable.other. Given the popularity of this theme, it is another strong reason for not highlighting variables.

from julia-sublime.

I notice that only functions in Base module are exported. The functions in Core module should also be considered.

from julia-sublime.

Thanks for that overview, I was about to change my mind based on this, until I found the official docs, according to which variable.other is supposed to be used like we do in this package. In light of this, what do you think regarding variable.other?

I was not aware of this documentation for scopes, perhaps we find more things that should be changed to follow these guidelines.

I agree with you regarding variable.parameter. This is now fixed in 6a56ed3.

I notice that only functions in Base module are exported. The functions in Core module should also be considered.

This is now fixed in 3ea5262.

from julia-sublime.

Great. I agree that we should keep variable.other. The solution for me now would be to modify my color scheme. Anyway, thanks for your responsive work!

from julia-sublime.

Sweet. Thanks for your constructive input!

from julia-sublime.