No parameter highlighting in VSCode Light/Dark Mode

[kiran-epic]

👓 What did you see?

When using VSCode in light /dark theme mode, the step parameters are not highlighted at all. The highlighting works when using other themes like light+/dark+

✅ What did you expect to see?

The parameter should be highlighted making it easier to identify

📦 Which tool/library version are you using?

Extension Version : 1.2.8 Extension Settings :

{
    "cucumber.features": [
        "cypress/e2e/features/**/*.feature"
    ],
    "cucumber.glue": [
        "cypress/e2e/step_definitions/**/*.ts"
    ]
}

🔬 How could we reproduce it?

Steps to reproduce the behavior:

1. Install the extension & configure it such that the step definitions are available for the extension to parse the steps
2. Switch the Visual Studio Theme (Code -> Preferences -> Color Theme ->Light (Visual Studio)

Light Mode (Visual Studio)

Dark Mode (Visual Studio)

📚 Any additional context?

---

This text was originally generated from a template, then edited by hand. You can modify the template here.

[aslakhellesoy]

We use the parameter semantic token type to highlight parameters. It is also referenced in the docs

It appears that some VSCode themes don't have a style for this token type. For example:

• Dark (Visual Studio) - no styling of param
• Dark+ (default dark) - has styling of param

We need to study the semantic highlight guide and syntax highlight guide more closely to get to the bottom of this I think.

The scope inspector might also help.

[nklowns]

Mine Dark+ (default dark) dont highlight How can I help debugging this?

[cortexcompiler]

I was not getting syntax highlighting in some of my Dark mode color themes and this comment fixed it for me through the addition of this setting:

    "[cucumber]": {
        "editor.semanticHighlighting.enabled": true
    },

[kieran-ryan]

Glad this resolved the issue for you @cortexcompiler and appreciate you contributing that mitigation.

Have raised a PR so that the extension enables semantic highlighting by default for gherkin, so modifying configuration depending on colour theme will not be required.

Would you be able to provide the names of some colour themes where you experienced the issued and the configuration resolved? Would like to test against them to ensure properly resolves the issue in your case. A quick try of the above configuration with 'GitHub Dark' and 'GitHub Light' did not appear to work for me - though the '+' versions of both work without configuration; interested if works for you, and what version of VSCode you are using?

[fitzsimb]

The real issue here is that parameters aren't given proper context highlighting when used in a Scenario Outline, but they do have proper highlighting in a regular scenario. Excuse the screentshot:

[fitzsimb]

The real issue here is that parameters aren't given proper context highlighting when used in a Scenario Outline, but they do have proper highlighting in a regular scenario. Excuse the screentshot:

A small update to this, it's the presence of the Examples section that breaks the parameter context highlighting. Removing Examples made it highlight correctly.

[kieran-ryan]

Thanks for highlighting @fitzsimb, and for your interest in the project.

This is marked as being by design as there were open points on how best to handle certain cases and conflicts with Scenario Outlines. Similarly, marking steps as undefined and go to step definition are also presently disabled with outlines; however support for marking undefined steps will be available once we propagate a release of the latest Language Service (v.1.6.0).

Would be great to get your perspective/ideas/thoughts on the below and what you would view as a suitable implementation and any potential issues or conflicts that should be considered (from #90):

Consider this example:

Scenario Outline:
  Given I have <count> cukes in my <container>

  Examples:
    | count | container |
    |     4 | basket    |
    |     7 | bag       |

This becomes two scenarios, each with the following step:

• Given I have 4 cukes in my basket
• Given I have 7 cukes in my bag

Now, imagine we have two step definitions with the following expressions:

• I have 4 cukes in my {word}
• I have {int} cukes in my bag

The first step would match the first expression, and the second step would match the second expression. Each match has only a single parameter.

How should we highlight in this case?

I suppose a compromise could be to highlight using matches if there are no <> placeholders, and highlight the <> placeholders otherwise.

[fitzsimb]

Thanks for highlighting @fitzsimb, and for your interest in the project.

This is marked as being by design as there were open points on how best to handle certain cases and conflicts with Scenario Outlines. Similarly, marking steps as undefined and go to step definition are also presently disabled with outlines; however support for marking undefined steps will be available once we propagate a release of the latest Language Service (v.1.6.0).

Would be great to get your perspective/ideas/thoughts on the below and what you would view as a suitable implementation and any potential issues or conflicts that should be considered (from #90):

Consider this example:

Scenario Outline:
  Given I have <count> cukes in my <container>

  Examples:
    | count | container |
    |     4 | basket    |
    |     7 | bag       |

This becomes two scenarios, each with the following step:

• Given I have 4 cukes in my basket
• Given I have 7 cukes in my bag

Now, imagine we have two step definitions with the following expressions:

• I have 4 cukes in my {word}
• I have {int} cukes in my bag

The first step would match the first expression, and the second step would match the second expression. Each match has only a single parameter. How should we highlight in this case? I suppose a compromise could be to highlight using matches if there are no <> placeholders, and highlight the <> placeholders otherwise.

Hey Kieran-Ryan, I don’t know that I agree with the assertion here. The issue is that normal parameters aren’t being highlighted, not just the parameters from the Examples section. If that’s fixed with the latest language model, that would be great.

As for your example, I would have the feature file use a light blue underline on those steps, stating that they match multiple step definitions. Having that feature in general would be great, as I’ve had team members submit new step definitions that cause tests to fail because it created a match conflict.