Regression in keyword color coding in SlickEdit 2022 (27.x.x.x)

[spongyryno]

When editing a PowerShell (*.ps1) file in SlickEdit 26.0.1.0, by default, “switch” is a keyword, and it shows up colored as such. By comparison, “stitch” is not a keyword (see attached "sei1.png").

Doing the same thing in SlickEdit 27.0.2.0, even though “switch” is a keyword, it does not get colored as one (see attached "sei2.png").

In both cases, I have deleted my "My SlickEdit Config" folder, and started from scratch.

Removing the "switch" keyword and re-adding it doesn't help. The same issue is present for other keywords, too.

How can I work around this?

[Clark]

This is intentional. There's a regex which overrides keywords inside brackets in the "PowerShell Base" profile. Coloring these as keywords causes problems with smart editing/indenting. The "switch" word in your example is not part of an actual switch statement.

While you can change this back by making use of the "Order:" field for the "switch" keyword you added, I wouldn't recommend it. I think you would need to set it to -2. The regex override is set to -1.

[spongyryno]

What does that "order" mean?

I have always added the fundamental types (like "string") as keywords, because like keywords, they are part of the language. A "switch" type is just that, a type, in addition to a keyword. Therefore it should show up as such.

When I add the word "string" as a keyword (since it is one, as a fundamental type in PowerShell), it works correctly, even without changing the "order".

I rarely use "switch" statements in PowerShell because they're kind of clunky... but I use switch types all the time. If I have to choose, I would definitely choose the coloring to be correct when used as a type.

[Clark]

The "Order:" field effects order of evaluation. Multiple items can match the same item (in this case "switch"). You can specify that your item be matched earlier in the search order.