Support DAP's ValueFormat for formatting values in variables list

[DanTup]

I had a feature request to show Variables in hex format. I found supportsValueFormattingOptions /valueFormat but it seems that VS Code does not currently support it (see #28025 (comment)).

The recommendation in Nov 2020 was for debug extensions to implement a context menu entry to handle this:

#28025 (comment)

However, this is not an ideal solution because (if I understand correctly) it needs work both in the VS Code extension and in the DAP Server, including some custom way for the VS Code extension to pass this setting to the DAP Server (in some non-standard, VS-Code-extension-specific way).

It would be much better if VS Code had built-in UI for this and supported supportsValueFormattingOptions /valueFormat. In Mar 2021 at supportsValueFormattingOptions /valueFormat, @weinand said:

But as soon as VS Code will start using it, we will add "format" as an optional property on InlineValueContext.

So it seems like there may be a plan to move to this, but as far as I can tell there is no existing issue tracking/discussing it.

[DanTup]

@weinand I'm trying to decide whether it's worth doing something custom to support this for now, but I don't want to do so if a standard way might not be far off. I noticed this was assigned to On Deck. Do you think it's something that might happen in the near-term? I won't hold you to it, it'll just help me plan 😄

Thanks!

[DanTup]

@weinand I was looking to see if there's a way I could handle this in my extension for now (backed by a simple setting) until VS Code has support.

In #134452 (comment) you mentioned using a DebugAdapterTracker as middleware. I think I could use this to add in the supportsValueFormattingOptions/valueFormat fields on the outbound messages.

However, the docs for DebugAdapterTracker don't seem to mention that it's intended(/allowed) to manipulate requests in that way. Is this something that is accidental, or will it continue to be supported if we build on it?

[roblourens]

Yeah, it's not spelled out in the API. The vscode.d.ts says that your tracker factory returns

a "tracker" object that provides read-access to the communication between the editor and a debug adapter.

I think this just means it doesn't let you send entirely new messages, but you are able to modify messages. The implementation allows this and we've used it in the past, one example is here https://github.com/microsoft/vscode-nodebook/blob/8ba0d512482c56d08833fd22fe726ca46ea5e7e7/src/nodeKernel.ts#L99

[DanTup]

provides read-access

I think this just means it doesn't let you send entirely new messages, but you are able to modify messages.

Could this be updated to be more explicit? Sometimes functionality that isn't documented gets changed and it's more difficult to argue it should be fixed if it was never documented :-)