Highlight Base, Core and Main? about julia-sublime HOT 16 CLOSED

Pkg.add()

from julia-sublime.

Now all built-in modules are scoped with support.module. I fetch all built-in modules with

filter!(x -> isa(eval(x), Module), [names(Base); names(Core)])

Note that support.module is usually not highlighted, so this change will not be visible (with the default color scheme).

So far, I do not scope add in Pkg.add with support.function. I wish to discuss this with you: As I see it, ideally we have, in Pkg.add(), that Pkg is scoped with support.module and add is scoped with support.function. Similarly for all built-in modules and their built-in functions. The issue is that this leads to lots of special cases (there are 25 built-in modules), could be a mess to maintain. Should this be done or not, what do you think? (Regardless, built-in functions that can be directly used, such as abs(), get the scope support.function, but if this discussed part is not fixed, then abs in Base.abs() is not scoped with support.function.)

This also made me realize that . was always scoped as an operator. This was wrong, for example in

Module.foo()

the dot is not an operator, it should not be scoped as such. I've fixed this also, so that . is only scoped as an operator when it acts like an operator, the only case is broadcasting, such as in

foo.(vector)

from julia-sublime.

There are two three cases. Consider M.foo()

1. M is a supported module, but foo is not a supported (exported) function, e.g. Base.process_events().
2. M is not a supported module, but foo is a supported function. E.g. DataFrames.length().
   Though in practice, no one will perform such a call since length is available everywhere.
3. Both M and foo are supported.

I argue that in case 1, it should not be scoped to indicate that the function is not exported. And in cases 2 and 3, foo should be scoped as support.function.

With this logic,

• the add in Pkg.add() should not scoped as support.function
• length in Base.length() should scoped as support function
• length in DataFrames.length() should scoped as support function

It also raises another issue, consider the followings

Base.Base64.eval()
#      ^ this is a module

Base64 is currently scoped as variable.function, I guess the most appropriate scope is variable.other.member or simply variable.other.

from julia-sublime.

It also raises another issue ...

Yes, I messed up a bit. Fixed now!

How do we know that length in DataFrames.length() should scoped as support function? length is not necessarily available everywhere, and even if it is present, it is not necessarily a built-in.

Right now only supported functions from Base and Core are highlighted only when they are used directly, i.e. as abs() but not Base.abs().

from julia-sublime.

How do we know that length in DataFrames.length() should scoped as support function? length is not necessarily available everywhere, and even if it is present, it is not necessarily a built-in.

I think it is generally an error to override built-in functions without proper import. It is quite safe to assume that Module.length() is Base.length()

julia> type A end

julia> length(a::A) = 1
length (generic function with 1 method)

julia> length([1,2,3])
ERROR: MethodError: no method matching length(::Array{Int64,1})
you may have intended to import Base.length
Closest candidates are:
  length(::A) at REPL[2]:1

Also, it may be a nice feature to highlight those built-in functions to alert users that those names are already taken. They should either import the functions or use other names.

from julia-sublime.

I agree, but we are highlighting length() right now, but not SomeModule.length(). Whether or not SomeModule contains the method length cannot be known by the syntax highlighter. I don't see how we can improve this further.

from julia-sublime.

That is why I said they are available everywhere.

julia> module A end
A

julia> A.length([1,2,3])
3

from julia-sublime.

Aha, ok! So, how do we get a list of these always-present-methods? To extract the methods from Base I do names(Base). However,

julia> module A end
A

julia> names(A)
1-element Array{Symbol,1}:
 :A

julia> names(A, true, true)
5-element Array{Symbol,1}:
 Symbol("#eval")
 :A             
 :Any           
 :Tuple         
 :eval          

from julia-sublime.

I guess we should only scope the exported functions.

from julia-sublime.

So, no further changes?

from julia-sublime.

The only thing that I can think of now is the scope of A.length() as the function A.length is the same as Base.length.

from julia-sublime.

This discussion has shown that we want to be ambitious. This commit goes all the ways. Base.abs is highlighted as well as abs, also Pkg.add is highlighted. I do like python, I highlight both length and length() as support.function, of course only the latter has meta.function-call. Re-open if I missed anything.

from julia-sublime.

It would be nice to have a script to generate the the syntax file programmatically.

from julia-sublime.

I have included the code I used to fetch exported functions etc. in comments in the syntax file. See for example https://github.com/JuliaEditorSupport/Julia-sublime/blob/master/Julia.sublime-syntax#L31. Is this what you mean?

from julia-sublime.

I meant a script to load the .sublime-syntax and replace those lines directly. I thought about using YAML.jl, but all the comments may be lost.

from julia-sublime.

Cool idea! In the current state this might add more complexity than needed though. I'd prefer to keep it simple. However, if we get more and more generated regexes, going this route would be nice. At some stage one might even want to have auto completion for built-in functions and packages, with built in documentation for function call parameters etc. Something IDE-like. Perhaps as a separate package though, not everyone wants this from a syntax highlighting package. Maybe such IDE packages already exist, maybe one can build on sublime code intel or similar

from julia-sublime.