Configure Editor

This section describes the settings available to you to customize how Syside Editor works.

Note that Editor needs to be restarted for any changes to take effect.

syside.toml

Added in version 0.8.4: Support for syside.toml

This section does not apply to versions before 0.8.4.

Syside can be configured through syside.toml configuration file at the project or workspace root. If a path to configuration file is not provided, Syside will look for syside.toml in parent directories until either one is found, or a directory with a root marker is reached. Currently, root markers include:

  • .git for root git directory

  • sysand-lock.toml for root Sysand directory

This is the recommended way of configuring Syside in an editor agnostic way, and the only way to configure format options. Generally, any options provided through CLI will override options declared in the configuration file. This also applies to options declared in the editor, e.g. VS Code, settings. Furthermore, keeping these settings in a version tracked configuration file ensures that every team member working on the project maintains a consistent environment.

See Settings for all available configuration options.

Config File Discovery

Added in version 0.9.0: User configuration files

Since 0.9.0, Syside supports implicit merging of global and project user configuration options. Configuration objects, i.e. TOML tables, are merged recursively, while other values, like booleans and arrays, are overwritten if they are present in the next level configuration file. An exception to this is the exclude option which concatenates values, just like .gitignore would.

Configuration files are discovered and parsed in order:

  1. Global config found at:

    • Windows: %APPDATA%\syside\syside.toml

    • Linux/macOS: $XDG_CONFIG_HOME/syside/syside.toml if exists, otherwise $HOME/.config/syside/syside.toml

    This configuration can be transferred between machines. Unless a project config is found, paths will be resolved relative to the current working directory.

  2. Project-wide syside.toml. This configuration file is expected to be version controlled and shared between team members.

  3. Project-wide syside.user.toml in the same directory as syside.toml, or found the same way as syside.toml. This should only be used for user specific configuration options, e.g. lsp.inlay-hints, and not version controlled.

So for example, configuration options in syside.user.toml overwrite options in syside.toml, and options in syside.toml overwrite options in $HOME/.config/syside/syside.toml.

If only the global config is found, paths are resolved relative to the current working directory, otherwise they are resolved relative to the config file directory. An exception to this is using the --config CLI option explicitly which both disables config file discovery, and changes path resolution relative to the current working directory irrespective of the config file.

VS Code

Tip

VSCode has two types of settings: User and Workspace. User settings are meant for personal settings that apply to all of your projects. If you work in a team or have settings that should only apply to one project, consider using Workspace settings instead. For more information, refer to VSCode documentation linked above.

General Settings

  • syside.path – This setting overrides the path to the Syside language server executable. If this setting is not set, Editor extension will attempt to download the language server executable and use it.

  • syside.stdlib – equivalent to std configuration option. If set, this takes priority.

  • syside.completionLimit – equivalent to lsp.completion-limit configuration option. If set, this takes priority.

Logging

  • syside.log – This setting overrides the path to the log file of the Syside language server. If this setting is not set, Syside will use the default log file created in a location designated by Visual Studio Code. The currently used active log file’s path can be found in Visual Studio Code’s Output > Syside pane. Note that Syside attempts to rotate log files, however this may fail on certain configurations, e.g. Windows and VS Code when the log file is open in another process, in which case the log file will be overwritten.

  • syside.logLevel – This setting controls how much information Syside should record in the log file. Currently available options, listed from the most verbose to the least verbose:

    • trace – Should not be used day-to-day, only for troubleshooting. Contains all language server communication messages and their contents, leading to huge log files.

    • debug – Should not be used day-to-day, only for troubleshooting. Contains all language server communication messages, leading to huge log files.

    • info – The default. Good for day-to-day usage.

    • warning

    • error

    • critical

    • off – Completely disables any logging.

  • syside.telemetry.crashReports – equivalent to telemetry.crash-reports configuration option. If set, this takes priority. Additionally, crash reports can also be disable by setting VSCode-wide telemetry.telemetryLevel setting to off. For more information refer to What Data We Collect.

Controlling Which Files Are Analyzed

  • syside.include – equivalent to include configuration option. If set, this takes priority.

  • syside.exclude – equivalent to exclude configuration option. If set, this takes priority.

SysML Settings

  • syside.lineLength – equivalent to format.line-width configuration option. If set, this takes priority. Note that formatter does not have automatic paragraph wrapping for long comments, docs and notes. To help with comment, docs, and notes line lengths, Sensmetry recommends also setting the Visual Studio Code’s in-built editor.rulers setting to the same value, which will show you a ruler at the given character limit, enabling you to manually break down your comments according to the limit.

  • syside.edit – equivalent to lsp.edit configuration option. If set, this takes priority.