Highlighting Invalid Keywords / Common Language Mistakes - SyntaxEditor Python Language Add-on for WPF Forum

The latest build of this product (v26.1.0) was released 1 month ago, which was before this thread was created.

Posted 3 days ago by Jakub M - R&D Engineer, Hitachi Energy

Version: 26.1.0

Hi,

We are using the Actipro SyntaxEditor with Python syntax highlighting and were wondering whether there is any built-in setting, add-on, or recommended approach to flag common language mistakes that are syntactically valid text but semantically incorrect Python.

For example:

test = true
test2 = True

In Python, True is the valid boolean literal, while true is not defined and will result in a runtime error (unless a variable named true exists).

Currently, both lines appear identical in the editor. The editor does not visually indicate that true is likely incorrect, so the issue is only discovered when the script is executed.

Is there any functionality available that could:

Highlight unknown identifiers differently from Python keywords/built-in constants?
Perform semantic analysis beyond syntax highlighting?
Provide warnings for commonly mistaken keywords such as true vs True, false vs False, none vs None, etc.?
Integrate with a Python parser or analyzer that can surface such issues directly in the editor?

Our goal is not necessarily to have full IntelliSense or advanced static code analysis implemented directly by SyntaxEditor. We are aware that tools such as Pyright or Ruff can detect issues like undefined names and other code-quality problems.

However, we'd like to understand what capabilities SyntaxEditor provides out of the box. Is there any built-in functionality that can visually indicate potentially incorrect identifiers, undefined names, or common Python mistakes.

If there is no built-in support for this, has anyone implemented something similar with SyntaxEditor, and would integrating an external analyzer (e.g., Pyright/Ruff) or extending the parser/classifier be the recommended approach?

Thanks!

Comments (3)

Posted 2 days ago by Actipro Software Support - Cleveland, OH, USA

Hi Jakub,

The Python Language Add-on provides syntax highlighting and syntax checking, but it does not include a Python interpreter or semantic analysis to detect undefined identifiers. Names such as true, false, and none are syntactically valid identifiers, so the parser will not flag them simply because they may have been intended as True, False, or None. There is no built-in setting that enables those additional checks.

For additional validation, you could register a custom IParser service with the Python syntax language. Its Parse method could first call PythonParser.Parse to perform our built-in syntax checking, then run your own checks or invoke a third-party analyzer to identify undefined names and other potential mistakes.

The Python language expects the returned parse data to implement IPythonParseData. Your custom result would therefore need to preserve the data returned by PythonParser.Parse, including its existing errors, and merge in any additional errors you detect. Those combined errors can then appear in the editor as squiggle underlines with error descriptions on hover.

I hope that helps!

Actipro Software Support

Posted 1 days ago by Jakub M - R&D Engineer, Hitachi Energy

Hello,

Thank you for the explanation and for outlining the recommended approach.

One follow-up question: have you seen customers successfully integrate external analyzers such as Pyright or Ruff with SyntaxEditor in this way, or are there any best practices/examples you would recommend for surfacing third-party diagnostics through the parser pipeline?

Thanks again for your help!

Posted 1 days ago by Actipro Software Support - Cleveland, OH, USA

We have not had any customers share their individual implementations with us, so we don't know how well analyzers like Pyright or Ruff will work. Assuming those anylzers report errors that can be mapped back to the original source, you should be able to integrate the results into the parser pipeline. You'd just need to include those errors in the IPythonParseData returned from the registered parser.

The most straight-forward approach would be to replace the default parser with your own that derives from PythonParser, overrides the CreateParseData method, and injects the results of your external analysis into the Errors collection PythonParseData generated by the base method.

Actipro Software Support

Add Comment

Please log in to a validated account to post comments.