Describe the bug
When I'm declaring stuff using normal Groovy code, the keywords used for declarations don't highlight very well.
I really wish the syntax highlighting here worked by taking the Groovy syntax highlighter and adding new keywords, since it looks like all of the pipeline-specific highlighting is just keywords. But short of doing that, we could at least highlight the most common Groovy syntax.
Expected behaviourdef should be highlighted using probably some storage scope (the Groovy syntax uses storage.type.def.groovy). Access modifiers should be highlighted using some storage.modifier (the Groovy syntax uses storage.modifier.access-control.groovy).
Ideally the identifier being declared should also be highlighted, though that requires more contextual awareness. It could at least be done for an identifier immediately after def, though I don't know if this is a good idea if it won't also work for e.g. String foo = … or String foo() { … }.
Actual behaviourdef is highlighted using strong.jenkinsfile, which means there's no semantic meaning whatsoever and it just appears bolded. Access modifiers aren't highlighted at all.
Describe the bug When I'm declaring stuff using normal Groovy code, the keywords used for declarations don't highlight very well.
I really wish the syntax highlighting here worked by taking the Groovy syntax highlighter and adding new keywords, since it looks like all of the pipeline-specific highlighting is just keywords. But short of doing that, we could at least highlight the most common Groovy syntax.
Expected behaviour
defshould be highlighted using probably somestoragescope (the Groovy syntax usesstorage.type.def.groovy). Access modifiers should be highlighted using somestorage.modifier(the Groovy syntax usesstorage.modifier.access-control.groovy).Ideally the identifier being declared should also be highlighted, though that requires more contextual awareness. It could at least be done for an identifier immediately after
def, though I don't know if this is a good idea if it won't also work for e.g.String foo = …orString foo() { … }.Actual behaviour
defis highlighted usingstrong.jenkinsfile, which means there's no semantic meaning whatsoever and it just appears bolded. Access modifiers aren't highlighted at all.Screenshots
Additional context Version 1.1.0