Weird decorators highlighting with default python syntax

[sterliakov]

Let's begin with an image:

I know for sure this change was introduced last year and is annoying me already for a while. Previously decorators used to be highlighted fully, including dotted paths. This looks annoying, especially for properties, but I'm ready to accept "works as intended" resolution too:)

Scopes are assigned as follows:

• Line start: source.python meta.annotation.python punctuation.definition.annotation.python
• "at" sign and lone decorator name: source.python meta.annotation.python variable.annotation.python
• dotted path: source.python meta.annotation.python meta.path.python meta.generic-name.python
• period in path: source.python meta.annotation.python meta.path.python punctuation.accessor.dot.python
• last path component: source.python meta.annotation.python meta.path.python variable.annotation.python

Tbh, this smells like a bug in ST syntax (why does variable.annotation.python not apply to qualifying components?) - if you agree, I'll address this question to ST team instead.

Code to reproduce:

@deco
def foo(x): pass


@foo.deco
def bar(x): pass


class A:
	@property
	def foo(x): pass

	@foo.setter
	def foo(x): pass

[MattDMo]

First off, I apologize for the 2-year wait. I've been away from programming for a while.

TLDR; I suspect this behavior is intended, although I haven't read through the Python.sublime-syntax commit messages and issues to confirm it. I can change it if you're interested.

Let me explain. "Normal" decorators such as @deco on the function foo() in your example are being highlighted as you would expect and as I intended with the color scheme. So far so good.

In the second example, you expect to see all of @foo.deco highlighted as bolded purple-ish text with a blue background, as defined in the Decorator scope definition, yet only the @ symbol and deco are being highlighted as such. This is most likely due to the fact that the deco() function acting as the decorator is contained within the foo module. The full, functional code would look like this:

import foo

@foo.deco
def bar(x): pass

I suspect the Python syntax's author(s) are trying to be very specific, as deco() is the actual decorating function and its location just happens to be in foo. Therefore, they are not highlighting foo. as it is simply the designator for the containing module. Does that make sense?

The author(s) of Github's Python highlighting rules seem to have gone in a different direction, styling decorators from the @ symbol up to the first non-alphanumeric character, then styling the rest as a different class. A deeply-nested decorator such as

@foo.bar.baz.quux
def my_func():
    pass

shows that the dots are the same style as the initial alphanumeric string. I will refrain from further analysis of this highlighting, as this response is getting too long already...

So, in conclusion, there are two options.

1. Keep things exactly the way they are and accept the Python.sublime-syntax authors' reasoning. Case closed.
2. Modify Neon's Decorator scope to include the meta.generic-name and punctuation.accessor.dot scopes so that everything is included. This may have unintended consequences elsewhere that I can't currently foresee.

If you're still interested in this at all, please let me know your thoughts.

[sterliakov]

Hi! First of all, I must thank you for this wonderful color scheme - I'm still using it happily:)

Consider the following scenarios:

1. "Regular" decorators - all parts belong to the semantic group, and I'd prefer them fully highlighted with a blue bg
2. Properties - unhighlighted prefix is a property name, and it's nice to see it separated. Yet this case is indistinguishable at the syntax level from the previous one...
3. "2nd-order" decorators (with arguments) - arguments definitely should not be highlighted, and the dotted path should be treated in the same way as in point 1

I tried to customize it a while ago. I did this:

        {
            "name": "Decorator",
            "scope": "meta.annotation meta.path",
            "foreground": "#B6B8FE",
            "background": "#07019A",
            "font_style": "bold"
        },

(and commented that out shortly after). This is just plain wrong and breaks decorator arguments (case 3) horribly. Here's a random example with that uncommented:

I didn't enjoy highlighting dotted paths in arguments as decorators, so had to get used to the new style:)