Change the value of expressions

[richardstanton]

Evaluation

With the addition of evaluateName on VarialesResponse, to complete the expression experience it should be possible to update the value of an expression. For this proposal, this adds the functionality to the evaluate request since that contains the context such as frameId that would be necessary to evaluate the expression.

Proposed protocol changes:

    /** Information about the capabilities of a debug adapter. */
    export interface Capabilities {
        // ...
        /** The debug adapter supports using evaluate to set the value of expressions. */
        supportsSetExpression?: boolean;
    }

    /** Arguments for 'evaluate' request. */
    export interface EvaluateArguments {
        // ...
        /** The optional value to set the expression to. */
        value?: string;
        // ...
    }

Read only properties

Some debuggers return additional information on classes. For example the size or capacity of a std:string. These properties are intended to be read-only, however this concept would need to be added to the protocol.

Proposed protocol changes:

    /** Response to 'evaluate' request. */
    export interface EvaluateResponse extends Response {
        body: {
            // ...
            /** Indicates the expressions value can be modified. */
            readOnly?: boolean;
        };
    }

    export interface Variable {
        // ...
        /** Indicates the variables value can be modified. */
        readOnly?: boolean;
        // ...
    }

Proposed pull request: #81

@weinand @jacdavis @gregg-miskelly @andrewcrawley @tzwlai

[gregg-miskelly]

Here is the corrected link to the PR: https://github.com/Microsoft/vscode-debugadapter-node/pull/81

[gregg-miskelly]

Repeating my suggestion from the PR:

Maybe this is just me, but I feel like this should be a separate request rather than overloading 'evaluate'.

Either way, I think you need a new capability for this one.

[weinand]

@richardstanton what is the use case (and UI) of the first part of this request?

[richardstanton]

@weinand The use case is that an expression that has been added to the watch window can have its value changes. For example a user might add an expression, such as data[1422].value and see its value in the watch window. The user can conveniently change the value in the watch window. Since expression might contain function calls or global values the user would not be able to change values from the locals window.

[weinand]

@richardstanton hmm, so I can change the value of an expression "3+4" to 12?

[richardstanton]

@weinand Debug adapters that implement this would also mark an expression such as this "read-only" so that the UI would not let you change the value. That is why the proposal combines both the set expression and read-only protocol changes. You can see this experience when debugging in Visual Studio.

[weinand]

@richardstanton thanks for helping me understand this (somewhat esoteric) feature of setting the value of an expression. I only see very few debug adapters implementing this (probably exactly one). I have to agree with @gregg-miskelly that it feels strange to make this feature a part of the evaluate.

[richardstanton]

@weinand @gregg-miskelly I am happy to make this its own request. How do you like this naming: setExpressionRequest, with arguments expression: string frameId?: integer

[gregg-miskelly]

@richardstanton sounds good to me

[weinand]

I propose that you add 'setExpressionRequest' as a private request first. VS Code will definitely not implement this in the near future and I would like to keep the protocol small.

[weinand]

After discussing this in the weekly planning call, we came to the conclusion that this protocol is too specific to be added to the VS Code debug protocol at the moment.

[weinand]

This feature is now available in the DAP as a "setExpression" request. See #167.