debugAdapter console intellisense Apis

[nojvek]

The current VSCode debugging experience feel subpar to that of chrome devtools or F12 console.

Proposal:

debugAdapter sends getConsoleCompletionsAtPosition(text: string, pos: number): ConsoleCompletions[] as user is typing.

debugAdapter returns back a list of completions
interface ConsoleCompletions {
text: string;
pos: number; // where to apply this completion
.. other info
}

I'm not sure of the exact completions structure but happy to have input from other adapter folks.

[weinand]

@nojvek I don't think that the debugAdapter is involved here. What is needed is access to the language model in the debug console (and all other places where language specific code is edited). The intellisense experience in the debug console should be the same as in the editor (and the editor doesn't use the debugAdapter for this).

[nojvek]

The language service might not always know what is possible at runtime. e.g
values of an array or objects created a runtime. The way this is done in JS
consoles is walking the prototype tree and properties.

On Sat, Jun 25, 2016 at 1:36 AM, Andre Weinand notifications@github.com
wrote:

@nojvek https://github.com/nojvek I don't think that the debugAdapter
is involved here. What is needed is access to the language model in the
debug console (and all other places where language specific code is
edited). The intellisense experience in the debug console should be the
same as in the editor (and the editor doesn't use the debugAdapter for
this).

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#8114 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AA-JVIdiGP7pRMOE-VbWhEwzKhvW_FwXks5qPOh9gaJpZM4I-AAT
.

[roblourens]

I agree with @nojvek, intellisense will be far more useful if the debug adapter is involved. For JS targets in particular, I think users will expect an F12/chrome devtools-like experience where intellisense shows properties that are actually available.

It would be interesting if the two data sources were mashed up, giving you available properties along with language service data when available, if that's feasible.

[weinand]

Yes, we are aiming for a combination of debug adapter and language service and we are planning to start with the debug adapter.

Here is the corresponding debug protocol feature request: microsoft/vscode-debugadapter-node#48

[nojvek]

This is awesome. Thanks Andre

When criteria do you think will determine it going into stable mode rather
than experimental mode?

On Thursday, July 21, 2016, Andre Weinand notifications@github.com wrote:

Yes, we are aiming for a combination of debug adapter and language service
and we are planning to start with the debug adapter.

Here is the corresponding debug protocol feature request:
microsoft/vscode-debugadapter-node#48
microsoft/vscode-debugadapter-node#48

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#8114 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA-JVMMUuejR79MmS_M9b2BVsBqzTYtwks5qXzrOgaJpZM4I-AAT
.

[weinand]

@nojvek as soon as we have implemented the frontend (UI) and at least one backend (node-debug) for it. Then we have a better understanding of the fine details of the protocol. The experimental API that I've added is just to get things started...

[isidorn]

@weinand Each suggestion needs to have a type and currently this is missing in the debug protocol

[weinand]

@isidorn ok, I'll add this. For now just hardcode 'property'

[weinand]

@isidorn I've added a type attribute to the CompletionItem type and node-debug now returns a 'function' type.