Python Syntax Highlighting

1

Hi All, I came across CodeMirror recently via Brackets. One of the things that caught my eye was the python syntax highlighting and how it didn’t match up with other IDEs that I have used in the past (including ST3). Note, I also checked this against the latest version of CodeMirror independently.

Having a look at the associated classes for each part of a line, I saw that for example, in general, the class “cm-builtin” was prioritised over “cm-variable”. This meant however, that should I create a dictionary with a key that matches a built-in function name (maybe not ideal, but allowed), it would get styled as either a variable or a built-in. This leads to different colored keys in a dictionary which is confusing :slight_smile:
I couldn’t help but wonder if there should be a way to give a specific class to “keys” rather than trying to parse as a variable or a built-in?

Secondly, when it comes to instantiation of classes, it’d be nice to have the class styled separately. Currently, it is classed as “cm-variable” which doesn’t help it stand out.

And lastly, I noticed that booleans, “True/False” are identified as “cm-keyword”, which is the same as “def” for example. It’d be great to also separate that out for readability.

While I don’t expect anyone to run out and implement any of these changes, it’d be great to get some feedback on whether the above nit-picking is due to my ignorance of the internals of CodeMirror (which would be great!), or whether they could be considered valid improvements?

2

Could you show a code example? If a word is used in property position (for example foo.abs), the Python mode appears to style it as cm-property, which seems correct. Aren’t dictionary keys in Python passed as strings in square brackets anyway?

A patch that adds cm-def to class definition names and method/function definition names, and one that styles True/False as cm-atom, would definitely be accepted.

3

Excellent to hear. I know python has it’s list of keywords (keywords.kwlist), but it’s not helpful for visualisation to paint all with the same color.
Is the best approach to getting this implemented creating my own patch and requesting a pull request on github, or requesting it as an improvement somewhere like here? Apologies for my newbieness!

Sure. There are are actually a couple of ways to instantiate a Python dictionary, based on preference and style. I guess in the second instance, you would be correct in saying it’s not an issue. I have always opted for the former, rather than the latter of the two ways below:

aaa = dict(
    id   = 'AAA',
    type = 'upper',
    true = True
)
bbb = {
    "id":   'bbb',
    "type": 3,
    "true": False
}

In these cases, the dictionary “aaa” would have the issue I mention, while bbb would not. Both formats are entirely valid Python syntax. I do believe that both methods should have similar behaviour. I can always write my code one way, but I cannot be certain that code I may re-use will always choose the same way. By identifying the keys of a dictionary and using a class (maybe as you say “cm-property”) instead of “cm-string”, “cm-variable” or “cm-builtin”, would make a big difference visually.

4

Yes, a pull request works best.

aaa = dict(
    id   = 'AAA',
    type = 'upper',
    true = True
)

Oh, I wasn’t aware of this syntax. Since the Python mode does a very shallow parse of the code, it wouldn’t be trivial to add special handling for this case (but it also wouldn’t be super hard).