First let me define what I mean with "jump" keywords. Things like if and else are of course also flow control keywords and they do result in the CPU executing branches, but I'm more specifically considering the jump in terms of visual code flow. For example, a subtle goto that radically changes the execution flow isn't always as visible as the effect it has.
Current scopes
In C these currently get the scope keyword.control.c, but this scope is also used (correctly) for if, while, and other actual flow control keywords.
In Python the scope is keyword.control.flow.python and includes loop keywords as well as return and raise.
New scopes
I suggest that some of these flow control keywords get scoped as two new flow control types - one type jumps within the current frame/call stack the other jumps out of the current call stack.
C
Jump "around"
goto
break
continue
Jump "out"
return
Some standard functions that also result in (possibly) dramatic call stack jumps and these should be scoped the same as the keywords.
exit()
assert()
C++
Jump "around"
Same as C
Jump "out"
Based on C
throw
Python
Jump "around"
break
continue
Notpass.
Jump "out"
return (already scoped with keyword.control.flow.return.python)
raise (already scoped with keyword.control.flow.raise.python)
assert
Perhaps yield ?
And many more languages with similar keywords/statements.
Alternative
The same colouring can be achieved if all languages define unique scopes for all flow control keywords. This will avoid having to define what each keyword's jump type is. Python has this for 2 keywords, Shell-Unix-Generic seems to have keyword.control.*.shell for all keywords. A colour scheme can then add each of these to colour them as desired. It does mean that the colour scheme now defines what jump type a jump keyword is, which may or may not matter.
Example screenshots
Current:
Proposed, using new scopes with illustrative colours:
Intro
First let me define what I mean with "jump" keywords. Things like
ifandelseare of course also flow control keywords and they do result in the CPU executing branches, but I'm more specifically considering the jump in terms of visual code flow. For example, a subtlegotothat radically changes the execution flow isn't always as visible as the effect it has.Current scopes
In
Cthese currently get the scopekeyword.control.c, but this scope is also used (correctly) forif,while, and other actual flow control keywords.In
Pythonthe scope iskeyword.control.flow.pythonand includes loop keywords as well asreturnandraise.New scopes
I suggest that some of these flow control keywords get scoped as two new flow control types - one type jumps within the current frame/call stack the other jumps out of the current call stack.
Cgotobreakcontinuereturnexit()assert()C++CCthrowPythonbreakcontinuepass.return(already scoped withkeyword.control.flow.return.python)raise(already scoped withkeyword.control.flow.raise.python)assertyield?And many more languages with similar keywords/statements.
Alternative
The same colouring can be achieved if all languages define unique scopes for all flow control keywords. This will avoid having to define what each keyword's jump type is.
Pythonhas this for 2 keywords,Shell-Unix-Genericseems to havekeyword.control.*.shellfor all keywords. A colour scheme can then add each of these to colour them as desired. It does mean that the colour scheme now defines what jump type a jump keyword is, which may or may not matter.Example screenshots
Current:
Proposed, using new scopes with illustrative colours: