[Python] Tweak keyword scopes

[deathaxe]

This PR...

1. scopes with keyword.control.context.with as flow may be dedicated to return, continue, ... .
2. scopes async as part of corresponding control keyword to ensure consistent highlighting in default and basic color schemes. (For details, please refer to commit message).

Before:

After:

[michaelblyons]

I support change 1. I am ambivalent about change 2.

[deathaxe]

In general I prefer dedicated scopes for single keywords as well. I also dislike how as keywords' scope is lumbered under related control keyword scopes instead of assigning keyword.operator.assignment.as.

An alternative solution may be to just consume both async for and for as keyword.control.loop.for without specially targetting async. That's what we do in SQL various times. I mean, someone could have been more creative than copying from JavaScript and use afor adef or awith. ;-)

I stumbled over both of async def looking equally while control flow differs, which is not ideal. My every day color scheme doesn't distinguish modifiers and control flow keywords. Thus inconsistent highlighting just revealed by luck.

Alternatives wellcome.

[michaelblyons]

I didn't notice in your first screenshots that you're matching the async with more closely to what async def already has.

Is there a scope name that could cover the asyncness of both a with and a def, ideally that we could also use back in JavaScript and friends? I ask because I could see someone wanting to flag async code without a big union of three-level scopes.

I guess I'm okay with this change and and RFC to talk about async more generally.

I also dislike how as keywords' scope is lumbered under related control keyword scopes instead of assigning keyword.operator.assignment.as.

I am interested in this idea.

[deathaxe]

There are no dedicated async scopes. The only thing I found was in JavaScript async functions, which was applied to async def, while lazily choosing storage.modifier for other asyncs.

I am tempted to just treat them as ordinary keyword.control same as their synchrounous counter parts.

[FichteFoll]

Ultimately, from an algorithmic pov it does not matter whether the for or with statement you are using is asnychronous or not since it does not affect the logic of your body. It only marks points where execution may be halted while waiting for something, which is arguably not important enough to be highlighted specifically. It's a bit more important than async def because that is primarily a marker (and affects the return type of the function invocation), but it's not enough.

In that sense, asnyc for is much closer to await, but I do not think we have a scope name that could express this behavior appropriately.