Currently, data shown to users in OutputEvent.output and Variable.value is specified1 as plain text without any styling. Allowing for basic styling of this text would be useful to allow the data to be more readable. For example, in Chrome devtools:
Some tools in the browser world allow for styling of inspector output with HTML or a subset of HTML, but this is generally complex for clients to implement, especially ones that are not based on web tools. Instead, I suggest we allow for basic ANSI sequences to be used in both of these fields. While there are a wide range of sequences applicable only to terminals, we should suggest clients only care about the relevant color and text styling ones, and ignore and strip any they do not know about or wish to respect.
This entails the following updates. Both client and DA capabilities are needed -- clients so a DA can know whether to send such sequences, and DA's so clients can know whether to parse for ANSI sequences or display them directly:
interface Capabilities {
/**
* The debug adapter supports ANSI escape sequences in styling of
* `OutputEvent.output` and `Variable.value` fields.
*/
supportsANSIStyling?: boolean;
// ...
}
interface InitializeRequestArguments {
/**
* The client will interpret ANSI escape sequences in the display of
* `OutputEvent.output` and `Variable.value` fields when
* `Capabilities.supportsANSIStyling` is also enabled.
*/
supportsANSIStyling?: boolean;
// ...
}
interface OutputEvent extends Event {
event: 'output';
body: {
/**
* The output to report.
*
+ * ANSI escape sequences may be used to inflience text color and styling
+ * if `supportsANSIStyling` is present in both the adapter's `Capabilities`
+ * and the client's `InitializeRequestArguments`. A client may strip any
+ * unrecognized ANSI sequences.
+ *
+ * If the `supportsANSIStyling` capabilities are not both true, then the
+ * client should display the output literally.
*/
output: string;
// ...
}
}
interface Variable {
/**
* The variable's name.
*/
name: string;
/**
* The variable's value.
* This can be a multi-line text, e.g. for a function the body of a function.
* For structured variables (which do not have a simple value), it is
* recommended to provide a one-line representation of the structured object.
* This helps to identify the structured object in the collapsed state when
* its children are not yet visible.
* An empty string can be used if no value should be shown in the UI.
*
+ * ANSI escape sequences may be used to inflience text color and styling
+ * if `supportsANSIStyling` is present in both the adapter's `Capabilities`
+ * and the client's `InitializeRequestArguments`. A client may strip any
+ * unrecognized ANSI sequences.
+ *
+ * If the `supportsANSIStyling` capabilities are not both true, then the
+ * client should display the value literally.
*/
value: string;
1 While not specified, it's notable that VS Code interprets ANSI sequences OutputEvent.output data when no variablesReference is present, but not Variable.value.
Currently, data shown to users in
OutputEvent.output
andVariable.value
is specified1 as plain text without any styling. Allowing for basic styling of this text would be useful to allow the data to be more readable. For example, in Chrome devtools:Some tools in the browser world allow for styling of inspector output with HTML or a subset of HTML, but this is generally complex for clients to implement, especially ones that are not based on web tools. Instead, I suggest we allow for basic ANSI sequences to be used in both of these fields. While there are a wide range of sequences applicable only to terminals, we should suggest clients only care about the relevant color and text styling ones, and ignore and strip any they do not know about or wish to respect.
This entails the following updates. Both client and DA capabilities are needed -- clients so a DA can know whether to send such sequences, and DA's so clients can know whether to parse for ANSI sequences or display them directly:
1 While not specified, it's notable that VS Code interprets ANSI sequences
OutputEvent.output
data when novariablesReference
is present, but notVariable.value
.