Syntax highlighting issues in Juno(language-julia)

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
image
with e.g. Gruvbox Plus
image

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

  1. tokenize in/isa as keywords instead of operators
  2. maybe add undef to the list of built-ins
  3. add getproperty tokenization 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 :slight_smile:

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.

2 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
20%20PM