Syntax Highlighting Improvements

[stekyne]

Thought it might be useful to put down the ideas we'd like for the syntax highlighting. I've been looking at the docs a lot more but haven't really added much in terms of features yet.

The direct translation of Nate's grammar files has been a great help but the look is not translating 100%. I would also like to change some things from a taste point of view. That's my main reason for starting this discussion.

https://user-images.githubusercontent.com/14102861/28718447-0bafd418-7374-11e7-9848-3eef56a213fb.png

The image above shows the Atom version. Some things I'd like to see different.

1. The high-level document sections (eg. CsOptions, CsInstruments) have the same colour as variables which have the same colours as opcodes and opcode arguments. I don't think this is a good use of colour(s) and doesn't make it more readable.

2. The variables (i, a, k etc) highlight the start character only and all have the same colour. This is a taste thing I guess but it can be hard to see the highlight when it's only character wide. I think I'd prefer the whole token to get highlighted to make it clearer. Also, maybe have different colours based on what type of signal/rate the variable is. This could mean too much colour(s)/visual noise though so I guess there would need to be a balance. I definitely see a benefit to contrasting i, a and k-rates though.

3. Instr keyword (I think other keywords as well) and operator colouring are the same, should be different.

Any ideas/comments? I'm going to experiment with the above 3 things and make a prototype to see how it looks.

[kunstmusik]

1 and 3 sound good to me, 2 I have a hard time visualizing. I found the single first letter highlighting a bit odd myself but I can see the value of it. I do think it's not going to be as good an idea once we move to Csound 7 where variable types don't necessarily correspond with variable name conventions though.

[rorywalsh]

Just to say, I'm not a big fan of having only the first letter of a variable coloured. I find it a little odd too. I'm not against the idea of different colours for different variables types though.

[stekyne]

Ok great, we have some agreement at least! I'll work on 1 + 3 so and take it from there.

As for 2, it's not working in VSCode anyway so I guess I can leave it as is for now.

[stekyne]

Added some changes as described above. I left in the variable, start letter only highlighting (after I figured out how to do it right...). I think it looks OK in some colour schemes but I'm going to experiment a bit more.

[kunstmusik]

Works here but I still find the first-letter highlight odd. Let me know when you think it's ready for a release.

…

On Wed, May 9, 2018 at 5:54 PM, Stephen Kyne ***@***.***> wrote: Added some changes as described above. I left in the variable, start letter only highlighting (after I figured out how to do it right...). I think it looks OK in some colour schemes but I'm going to experiment a bit more. [image: image] <https://user-images.githubusercontent.com/2091399/39841659-7424b728-53db-11e8-83a2-3fbc34bca0f4.png> — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#1 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABjAe9ZoWQf4UfmB-64yIkfboDULsK3yks5tw2WJgaJpZM4Tviw6> .

[rorywalsh]

Looks nice. I'm not a fan of first letter highlighting, but to be honest, I could get used to it pretty quick. I might even grow to like it ;) Note that the letter following a 'g' should also be highlighted right? As in the case above with givar?

[stekyne]

Yeah true Rory!

To be honest I don't really like it either. It just seems weird. I do think it's a good idea to have some visual indication of a difference between variables though.

@kunstmusik You mentioned earlier "Csound 7 where variable types don't necessarily correspond with variable name conventions though.", can you explain this a bit maybe? Does that mean that the types will be inferred by the compiler and they can have any name?

[kunstmusik]

@stekyne : CS7 should have explicitly typed variables, but not inferred ones. (At least, that is not planned at the moment.)

You can see the syntax from some test CSDs in the feature/parser3 branch: https://github.com/csound/csound/blob/feature/parser3/tests/commandline/structs/test_structs.csd

[stekyne]

Looks cool! I get what you mean now. I was assuming that there was no left hand type declaration.

[nwhetsell]

I thought I should comment on some of this.

The high-level document sections (eg. CsOptions, CsInstruments) have the same colour as variables which have the same colours as opcodes and opcode arguments. I don't think this is a good use of colour(s) and doesn't make it more readable.

This is a consequence of the Atom theme I used to make the screenshot (Solarized Light); the colors used for various syntax scopes are here. The exact same grammar is used to highlight files (like xanadu.csd) on GitHub, with different colors used for different scopes.

The variables (i, a, k etc) highlight the start character only and all have the same colour. This is a taste thing I guess but it can be hard to see the highlight when it's only character wide. I think I'd prefer the whole token to get highlighted to make it clearer. Also, maybe have different colours based on what type of signal/rate the variable is. This could mean too much colour(s)/visual noise though so I guess there would need to be a balance. I definitely see a benefit to contrasting i, a and k-rates though.

This isn’t quite right. Type prefixes of variable names aren’t scoped in my orchestra grammar. Doing this in a CSON (or JSON) grammar is, I believe, not possible in general because of things like this:

opcode aUDO, 0, k
  aUDO kThing
endop

The a in aUDO is not a type prefix, but there’s really no way for a CSON grammar to know that. Scoping type prefixes is actually happening in CoffeeScript as part of an Atom grammar pattern subclass:

https://github.com/nwhetsell/language-csound/blob/55281ddd416be7356f205dbe53e5723aea020ffa/lib/csound-pattern.coffee#L46-L73

Instr keyword (I think other keywords as well) and operator colouring are the same, should be different.

This, again, depends on the color theme used. Some themes give keyword.function scopes a different color than keyword.operator scopes, but many don’t. If you want to see what different colors for those scopes could look like, I also wrote the Csound mode for the Ace editor. Try its kitchen sink demo with the Csound document and the Chaos theme.

[stekyne]

Thanks Nate. You are right, it's up to the theme to decide what colours it sets for the scopes. I didn't fully appreciate that at the time of writing the initial post.

Interesting, that is why the type prefix was lost when I converted to JSON (from CSON). I was wondering where that was implemented.

That's good food for thought. I'll take a look again.