Syntax Highlighting for Functions and Function Parameters

[alpaka]

I've searched in the Tools->Options page under Fonts and Colors, but was unfortunately unable to find settings that would allow me to enable syntax highlighting for known function names and function parameters - I also searched the internet and was similarly unable to find anything about the topic.

Therefore, I would like to request that these be added at your convenience, as these highlighting schemes make editing code much easier: For known functions, it is highly desirable to be able to differentiate between functions and data at a glance. For function parameters, it is very useful to be able to tell them apart from local variables (currently, I'm using something like Hungarian notation and adding a p in front of the parameter name, but highlighting would be much preferred).

If youˈre still willing, this would be a bonus highlighting feature: if local variables could be differentiated from global or closed variables, it would also make our lives easier, but this seems to me to be less important for typical workflows (going outside the scope of your function and parameters is probably not the best choice in most cases).

Thanks a lot for your consideration

[hongooi73]

Piggybacking on this: I think having more categories for syntax highlighting would be nice.

For example, this is how Github does it:

And the same code in RTVS:

Colorising function argument names at least would be great. If there's an existing way to do it in VS, I haven't found it.

[mkoohafkan]

I actually find the named argument hightlighting in your example very distracting, so I would hope that feature would be optional if implemented. Highlighting = already makes it easy to identify named arguments.

It would be nice to see function highlighting, but this is difficult since variable names can overwrite function names. The same issue came up in a discussion of R syntax highlighting in Notepad++. I think a good convention could be to apply function highlighting based on detection of (). This would also differentiate between cases where a function is being called (is_highlighted()) and where a function is being passed (do_something(d, fun = is_not_highlighted) or temp.fun = is_not_highlighted).

At the same time, I find it a bit weird that all statements with is. or as. prefix get highlighted (even when they don't exist, e.g. is.foo) when other known functions do not (including those that follow Hadley's naming convention of using _ for functions and . for variables, e.g. as_data_frame).

Differentiating between local and global variables in the editor sounds like a nightmare. You'd need code analysis tools just to visualize and there are too many edge cases. What about local variables with the same name as global variables? What about attached objects or variables inside environments? What about Rmd files and code chunks? Sounds like a mess.

[alpaka]

Highlighting is usually indeed optional. In VS you can adjust highlighting settings by going to Tools->Options then Environment->Fonts and Colors. It's a little unwieldy because you can't filter them by context, but it's not that bad. My presumption was that any such settings would end up there.

Also note that you can always make certain highlighting less distracting by matching the brightness more closely to the regular font color (in custom colors, this would be the Luminance channel). Most code editors in my opinion have far too large a brightness contrast between font and highlighted text.

As for function highlighting, IntelliSense can already tell you that something is a function in auto complete (purple cube/hexagon as opposed to a blue box) so it shouldn't be that much work. Intuitively, I'd expect this to actually be easier for languages with first level functions that can be inspected to reveal they are functions than for languages like C.

[MikhailArkhipov]

Brightness levels usually are dictated by accessibility/universal access. 4:1 contrast is typically required.

Speaking of colorization, semantic coloring (i.e. knowing that token is local variable or an argument) is tricky. Colorizer must perform fast as you type so it can't really be working of the parse tree (aka AST) since tree takes much longer to construct. Some languages perform two-pass coloring, first by keyword/token type then by AST when it becomes available. This causes visible delay though as not all colors are available right away and semantic colorization usually is a bit off as you type.