Feature request: show values of object properties on mouse hover while debugging

[AndrewFerr]

While debugging a Node application, hovering the mouse over a variable in the current scope will show its value in a popup. However, this does not work for variables' properties.

For example, hovering over a value named obj works, but not obj.propertyName, which instead just shows a documentation popup.

This means the only way to look up object properties is to use the Variables view, which can be cumbersome if a property is deeply nested (like obj.subObj.anotherSubObj.propertyName) or if the variable is in a nested scope (in which case you have to know/find the correct Block/Local/Closure scope that the variable resides in).

It would be helpful if the mouse hover popup could effectively do the work of digging through the Variables view for you.

[mickaelistria]

I had a quick look at the feasability and it seems affordable: it looks like Wild Web Developer "only" has to provide an Adapter(ITextSelection->IVariable) that would expand the evaluation to also include the dereferenced object.
If anyone wants to try contributing one, it would be welcome!

[AndrewFerr]

Turns out the adapter is provided not by WWD, but by lsp4e, via org.eclipse.lsp4e.debug.breakpoints.TextSelectionToIVariable. With that said, this issue may be moved to that project.

The main work is done in findVariableName, which simply finds the "whole name" of the word under the mouse cursor.

Though a quick fix can be made for this to support nested JS/TS objects, it looks like this adapter covers more than just the Node debugger, and thus must remain generic to any kind of source file that may be debugged. Can this somehow delegate the job of variable-region finding to a language server?

[mickaelistria]

Turns out the adapter is provided not by WWD, but by lsp4e, via org.eclipse.lsp4e.debug.breakpoints.TextSelectionToIVariable. With that said, this issue may be moved to that project.

Several adapters can be contributed. As a 1st step, Wild Web Developer can contribute a JavaScript-specific adapter, taking care of finding the right expression to evaluate.

Can this somehow delegate the job of variable-region finding to a language server?

I don't think LSP has this capability (I may have missed it though). If it doesn't, then Wild Web Developer will have to implement some expansion of the current selection to an evaluatable expression in its adapter.

[mickaelistria]

Would you be interested in trying to contribute this?

[AndrewFerr]

Would you be interested in trying to contribute this?

Yes I would; I've been trying to get a hold of my old Eclipse account for this purpose 🙂

[AndrewFerr]

What's interesting is that mouse hovers for object properties work for non-debug mode / documentation popups. Surely there's some way to let debug hovers "see" the same variable that's used by documentation popups?

[mickaelistria]

It's a bit tricky. There are 2 worlds: the edition world, which is powered by the Language Server (Protocol) and the debug world, that is powered by the Debug Adapter (Protocol). When hovering, the Language Server does the resolution job on its end and returns the documentation to display, the IDE doesn't really know anything about the file structure; when debugging, the Debug Adapter expects the IDE to provide interesting requests, some of them -such as dereferencing a property- do require some understanding of the language (which the IDE doesn't have by default since the understanding of the language is internal to the language server).
As far as I know, there isn't an obvious possible link to get from the language server an interesting expression to evaluate from a location; so we need to have some logic on the IDE at the moment. Also, the debug adapter protocol doesn't seem smart enough (yet?) to return an evaluation for a given location and requires the IDE to build an expression; which is not always easy nor reliable.
I think the DAP itself needs to be improve to provide some evaluate(Postion) operation; and that position would return the value and the range of the file on which it applies. If we have it, then we could most likely improve the strategy in LSP4E to show better values.

[mickaelistria]

I found microsoft/debug-adapter-protocol#343 which is related.