Hi all,
I was poking around and endlessly customizing my stylesheet in atom and got to wondering whether it would be useful to bring Juno’s naming conventions more in line with various other language packages in Atom. I have often noticed that common syntax themes had a less than impressive appearance when applied to Julia, and was wondering if i was missing something that would improve my experience. If this is a common enough problem I would love to take a couple of days and revamp some of the syntax labeling. Likewise, if i am missing some easy customization i would be equally happy. I realize that many themes include custom styles, but i think Julia is lacking even a basic alignment with common standards.
Do you have any concrete examples where we don’t conform with “common syntax themes”? Imho language-julia looks fairly good with One Dark/Light, which are the de-facto standard.
Of course that theme makes the choice to e.g. not highlight operators, but that’s not something we should mess with I think.
Compare One Dark
with e.g. Gruvbox Plus
I realize that many themes include custom styles, but i think Julia is lacking even a basic alignment with common standards.
So far surprisingly few people have complained about that. I’m also not sure what you base the common standards on, considering that there’s no documented API except for the theme implementation that’s shipped with Atom.
1 Like
My choice of words was pretty poor in regard to “common standards” but i think there are a couple of issues with the way the tokens are named. Taking a look at One Dark, I think that more of the theme designers colors are incorporated due to tokenization of properties/fields and variables.
I agree that this lies in the dangerous realm of personal preference, and that if this isn’t a common complaint then it is far better solved by the customization provided by Atom.
Hm, so a couple of things we could improve (judging by your screenshot) would be
- tokenize
in/isaas keywords instead of operators - maybe add
undefto the list of built-ins - add
getpropertytokenization for.*\.\w*(basically)
Anything else you’d like to see?
3 Likes
Along with your list I would include parsing module names and struct names. Additionally it would be nice to highlight qualified imports like
import LinearAlgebra
LinearAlgebra.BLAS
It’s not really possible to do that with Atom’s regex based syntax highlighting, afaict.
I think it would be doable but you would have to be careful. I would try and make sure it gets treated like a “Class” for highlighting purposes.
But how would you distinguish
foo = Foo(1,2)
foo.field1
from
using Bar
Bar.foo
? A CamelCase heuristic might work, but doesn’t seem like a great idea to me.
Haha, I personally use the camelcase for my own highlighting, but yeah, I don’t think that’s a universal solution. If I come up with anything better I’ll submit a pull 
1 Like
There’s no syntactic distinction between property access and qualified name access, so it seems like trying to color them differently would be error prone at best and potentially misleading.
3 Likes
Cooked this up,
What do you think about the style? I think that adding a new root group for types as well as moving them out of the “support” category will look pretty nice.
3 Likes
Looks pretty neat, mostly. Wanna open a PR so we can iterate on it?
I seems to have incorrect text highlighting in Juno. You can try it out for yourself with this code snippets.
str = " hello world "
newstr = replace(str,r"^\s+" => s"")
newstr = replace(newstr,r"\s+$" => s"")
Picture of incorrect hightlighting
Hey, did this go anywhere? I really like this seperated highlighting for types, and would love to get my Atom to look like this.
2 Likes
Kinda:
https://github.com/JuliaEditorSupport/atom-language-julia/pull/189
Didn’t yet find the time/motivation to look into this, sorry.
1 Like