Spice up your source code with new colors

Business Central 2022 Wave 1 contains an excellent new way for source code highlighting. In this video, I show how to activate it, check it out:

https://youtu.be/cTc0kYFsAr0

In this video, Erik walks through a handy new feature introduced in Business Central version 20: semantic syntax highlighting for AL source code in Visual Studio Code. This small but impactful change leverages the AL compiler to provide much richer and more granular color coding of your source code, making it easier to distinguish between variables, parameters, built-in functions, local functions, and fields at a glance.

The Problem with Traditional Syntax Highlighting

Traditionally, Visual Studio Code uses a TextMate-based syntax highlighting system. This approach relies on a .tmLanguage file containing a collection of regular expressions (regex). When your source code matches one of these patterns, it gets assigned a token type, which determines its color.

While this system works and has served developers well for years, it has significant limitations. The regex-based approach can only make rough guesses about what a piece of code represents. For example, in a project working with FieldRef and RecordRef types, you might end up with large blocks of code that are all the same color — even though the individual elements serve very different purposes. Variables, built-in methods, and local functions all end up looking identical.

How Semantic Highlighting Works

The key insight behind semantic highlighting is that the AL compiler is already running in the background while you type. You can see this at work every time you get red squiggly lines under a syntax error — the compiler is continuously analyzing your code and knows exactly what each token represents.

Since the compiler already knows that a particular identifier is a variable, a parameter, a built-in function, or a local function, why not use that knowledge for syntax highlighting? That’s exactly what semantic highlighting does. Instead of relying solely on pattern matching, Visual Studio Code asks the compiler what each token actually is, and then assigns colors accordingly.

The result is far more granular and meaningful coloring:

  • Variables get their own distinct color
  • Parameters appear in orange, making them easy to distinguish from variables
  • Built-in functions (like FieldIndex on a RecordRef) get a different color than your own functions
  • Local functions appear in green
  • Microsoft-defined functions are visually distinct from your own custom functions
  • Fields are clearly identifiable

Enabling Semantic Highlighting

To enable this feature, you need to modify your Visual Studio Code settings. Open your settings.json file and add the following configuration:

"al.editor.semanticHighlighting.enabled": true

You can access your settings JSON by going to the VS Code settings UI, searching for any AL-related setting, and clicking through to the JSON file. Once you’re in the JSON file, create an AL section if one doesn’t already exist. As you type "al.", IntelliSense will suggest four editor settings. The one you want is editor.semanticHighlighting.enabled, which defaults to false.

Set it to true, save the settings file, and the change takes effect immediately — no restart required. You’ll see your source code transform with richer, more meaningful colors right away.

Performance Considerations

There’s one thing to be aware of: semantic highlighting relies on the compiler running in the background, which requires a tiny bit of additional processing power. The system is designed to handle this gracefully — when you first open a file, you’ll see the traditional regex-based colors initially. Once the compiler catches up and has fully analyzed the code, the colors will switch over to the more granular semantic highlighting.

A Practical Example

To illustrate the difference, consider a piece of AL code that works with record references and field references. Here’s the kind of AL code where semantic highlighting really shines — a page extension that uses a control add-in:

pageextension 55300 "Customer Card Youtube" extends "Customer Card"
{
    layout
    {
        addafter(Name)
        {
            usercontrol(Color; ColorPicker)
            {
                ApplicationArea = All;
                trigger ColorPicked(ColorInfo: Text)
                begin
                    Message(ColorInfo);
                end;
            }
        }
    }
}

With traditional highlighting, the ColorInfo parameter and other identifiers might all appear in the same color. With semantic highlighting enabled, you can immediately see that ColorInfo is a parameter (shown in orange), Message is a built-in function, and other elements each get their own distinct visual treatment.

Similarly, in a control add-in definition, the various elements become much more distinguishable:

controladdin ColorPicker
{
    StartupScript = 'startup.js';
    Scripts = 'jscolor.js';
    HorizontalStretch = true;
    VerticalStretch = true;
    RequestedHeight = 145;
    event ControlReady();
    event ColorPicked(ColorInfo: Text);
}

Conclusion

Semantic syntax highlighting is one of those small quality-of-life improvements that makes a real difference in day-to-day development. By letting the compiler inform the editor about what each piece of code actually represents, you get much richer visual feedback. You can instantly tell the difference between your own functions and Microsoft’s built-in ones, between variables and parameters, and between fields and local identifiers. It’s a simple setting change that’s well worth enabling in your AL development environment starting from version 20.

Picture of hougaard

hougaard