debug: support customizable pretty-printing of a struct

[stamblerre]

See the original request in microsoft/vscode-go#3032.
As @hyangah says, this is related to #100.

[esinek]

Found the feature I was referring to in the original ticket. Would be amazing if vscode-go had something similar. Feature and example linked below (using CPoint as an example)
https://docs.microsoft.com/en-us/visualstudio/debugger/create-custom-views-of-native-objects?view=vs-2019#BKMK_DisplayString

[polinasok]

@esinek Where exactly does a variable get displayed like this?
We are limited to whatever features the vscode editor and the debug adapter protocol support.

Are you looking for a mechanism to specify your own prettyprint logic or for the editor to provide some default option? Would it print something like what dlv cli prints in the terminal with the print command?

You can view the variable in the VARIABLES panel with all the nesting and options to expand and load each level. It can be tedious to expand all the nested fields, but I think you only need to do it once. The UI will keep them expanded and you will see as they change as the session progresses.

You can also view the variable in the WATCH panel. The same behavior with expanded fields preserved applies. Or you can use a function to print the variable with a recently implemented "call" expression.

We could also look into enabling supportsEvaluateForHovers, so the data hover triggers an Evaluate Request, which could return some kind of flattened string representation instead of a nested variable.

[esinek]

@polinasok

Where exactly does a variable get displayed like this?

In either VARIABLES or WATCH panes.

Are you looking for a mechanism to specify your own prettyprint logic or for the editor to provide some default option? Would it print something like what dlv cli prints in the terminal with the print command?

Yes, I think it would be reasonable to say I'm looking for a way to specify the prettyprint logic for a type, such that when that type appears in the VARIABLES or WATCH panes, VSCode will prettyprint in the format specified. Also with a way to switch between the prettyprinted value represented as a string and the raw value showing all the properties of the type.

You can view the variable in the VARIABLES panel with all the nesting and options to expand and load each level. It can be tedious to expand all the nested fields, but I think you only need to do it once. The UI will keep them expanded and you will see as they change as the session progresses.

The value add of having a configurable prettyprint per type is to reduce the noise in the VARIABLES or WATCH panes - in a single prettyprinted string, you can see the relevant information without having to use all the available real estate with opened trees of variables

You can also view the variable in the WATCH panel. The same behavior with expanded fields preserved applies. Or you can use a function to print the variable with a recently implemented "call" expression.

Will the "call" expression support printf like support (I haven't looked into that yet)? That would be a nice feature. It would still require making the "call" multiple times during a single debug session. And if you had multiple types you wanted prettyprinted, it could get tedious.

We could also look into enabling supportsEvaluateForHovers, so the data hover triggers an Evaluate Request, which could return some kind of flattened string representation instead of a nested variable.

The hover eval also sounds promising. If the hover is possible with some config per type, I would imagine the prettyprint config per type would also be possible

Thank you for your feedback and work on this topic and VSCode in general. It's always a tough trade-off between having an integrated set of really useful features vs a bag of unrelated features (which by themselves may be useful) which, in the end, makes the product a mess.

[polinasok]

We could look into some built-in pretty printing features on our end, but they would be based on built-in types and predefined. This could be made available either with hover or with a custom "print expression" option from the Debug Console or Watch, but there will not be a way for you to configure the pretty printing logic with those. The best I can think of is defining myTypeToString function per type in your program and then calling those using "call expression".

I am not aware of a central way to configure anything type-specific by the user. Maybe there are some custom editor plugins that could intercept the VariablesRequest in the editor and alter the way the UI reports them? But as far as I know nothing like this is available from inside the debug adapter. I do see supportsValueFormattingOptions in the spec, but it would only allow you to configure if the variable or expression value is to be displayed in hex only (details). Plus according to microsoft/VSDebugAdapterHost#10, this is supported in full Visual Studio, not VS Code (as of 2019 at least).

If you want this type of functionality made available in the editor+adapter, you need to file issues against:
Debug Adapter Protocol: https://github.com/Microsoft/debug-adapter-protocol/issues
VS Code: https://github.com/Microsoft/vscode/issues
Maybe we will get lucky and they will point us to some existing obscure hooks that I missed.

[hyangah]

Thanks @polinasok for investigating this issue and providing background, and @esinek for providing constructive user feedback.

To summarize, currently feasible options are:

1. predefine a pretty printing logic for type and call it using the call expression. Note that due to the complexity involved in Go's runtime, the call expression has its own limitations. See https://github.com/go-delve/delve/blob/master/Documentation/cli/README.md#call for the details.

2. users can enter a suitable delve expression (https://github.com/go-delve/delve/blob/master/Documentation/cli/expr.md) in the WATCH panel or DEBUG panel. (@polinasok is it not a possibility to introduce richer expression support in Delve DAP's evaluateRequest's expression than what delve's expression? I expect LogPoints support to be implemented in the future Delve DAP and then delve will need to implement interpolation of {} in expressions*. Then, can't that be utilized as the general evaluateRequest expression syntax? )

3. the custom view feature of visual studio is not available in vscode. The UI & interaction with the debug adapter is implemented by vscode, so this needs support from the vscode.

I don't see anything else which is feasible from this extension beyond these. I propose to close this issue.

(*) this expression interpolation is too javascript specific :-(

[rajveermalviya]

Will this cover formatting/pretty-printing time.Time values in some human readable format?
If not is it possible because currently debugging time related code, fmt.Println seems like the only way.

[polinasok]

@rajveermalviya If we were to add better pretty-printing, it would not be customized for time.Time. It would be more like what you would get using p <expression> from dlv cli or %#v formatting directive in Go - designed to inspect the underlying fields at a glance without needing to expand each one. If you want to view times in human readable format, I suggest using call expressions from DEBUG CONSOLE or WATCH.

[polinasok]

@hyangah Currently evaluate request just passes the expression to delve, which essentially returns back an anonymous variable with a type and a value. If the type is a scalar (int, string, etc), we display that scalar in the UI. If the type is a compound, we display some very basic single-line representation (usually just the type) with an option to expand to view the children variables. The expansion may trigger more requests to delve to evaluate additional expressions. If we were to treat expressions in {} as expressions, wouldn't we evaluate them the same way? We can always skip the expand-for-children part and only return the string representation of the value. In that case, we would need that string representation to be richer, more like what delve prints with multiple lines.