I’m thrilled about DAT syntax highlighting too - thanks so much for implementing!!
Naturally, I’m wondering how/if we can change the colours? There are some interesting choices with the default colourset and I suppose the easiest long-term solution is to let the user decide in Preferences/DATs.
Math symbols (=, <, >, !=, etc.) are tricky to read… would be great if these could be coloured orange or something different than variables. Sublime Text does this very well, much like how it handles if/in/etc.:
Thanks for the feedback. We will definitely be making the colors more configurable in upcoming builds as we continue developing the system - although possibly just through the textport. I’m not sure about building an interface for it at this point. The current colors were based roughly on visual studio’s color scheme just because that was what I was most used to
Regarding your observations:
In the current setup, comments are green and strings are red. So, even though the right example is using the docstring convention, it’s still technically a string rather than a comment. I had wondered about implementing an exception for this and coloring those like comments, but decided to wait on feedback from the team/community first.
Is it just the red string color, or would you expect fstrings to be handled differently than other strings? Our formatter isn’t fully parsing the text, so it isn’t generally aware of more complex structures.
I hadn’t thought of coloring math symbols differently since visual studio doesn’t, but that would be relatively straight forward to add if people are interested in it.
@ben Re: #1, yes, I saw the language par on the Common page. Very useful for adjusting colours, plus Edit → Auto Set DAT Language is super nifty for automating this process. (At first it was a bit confusing seeing that menu item there, but I understand it’s intent now and why it lives there. Makes sense.)
@robmc Thank you for your notes. It’s very helpful to know that this palette is inspired by Visual Studio.
Good point regarding the string vs. comments debate. I suppose for every rule there is an exception, and it’s safe to say that with triple quotes we’re usually writing a long comment, and that much red at once is a bit hard on the eyes. But, if it’s good enough for VS, then it’s probably good enough for Touch
For f-strings in particular it’d be nice to show variables inside of the curly brackets for easier referencing, similar to how VS Code handles them:
Regarding math symbols, you’re absolutely right, VS doesn’t colour those specifically, which is very interesting. I studied it more and noticed how they do offset the colour between variables and classes and booleans, in order to visually block things out a bit more. Of course, other applications like Sublime handle this a bit differently, but at the end of the day they all seem to have more in common than not.
One other thing I’m noticing is that VS Code/Sublime have slightly taller line spacing for the text - which usually improves readability, at least from a typography standpoint. Space is good Would be amazing if we could adjust this as well down the road…
Having enough visual distinction within each line of code makes for a much more pleasant programming experience, especially since so many TouchDesigner users, myself included, are “visual thinkers” (reminds me of the banner from the old Derivative website). Part of why this is such an important feature many of us are absolutely stoked about!
I’ve created a work item here to track some of these ideas and I expect it’s something we’ll be able to continue adjusting/improving as we go forward.
I’m leaning towards treating the docstring as a comment if we don’t run into any technical issues with it. I also like the idea about the fstrings.
As I mentioned, we’re not completely parsing the code (trying to do it on a line by line basis as much as possible for efficiency), so formatting that requires a broader understanding of the file is a little more challenging.
Adjusting the line spacing is easy to do as well. The DATs are essentially now Text COMPs under the hood, so anything you can do with that node is pretty easy in DATs
There are some interesting choices with the default colourset and I suppose the easiest long-term solution is to let the user decide in Preferences/DATs.
