Inlining values inside debugger

[lahodaj]

This is a prototype of a feature to show variable values directly in the editor, as permitted by the LSP protocol.

It looks like this inside VS Code:

and inside NetBeans:

[mbien]

really useful feature! We have to watch out for side effects of calling toString() though.

The debugger does have "Variable Formatters" which can be configured in the settings. Collections (which can be large) will only print their size by default for example. (but I imagine you are probably planning to do that anyway)

[lahodaj]

I did a lot of improvements lately. Lets see if this is heading in the right direction.

[lahodaj]

really useful feature! We have to watch out for side effects of calling toString() though.

The debugger does have "Variable Formatters" which can be configured in the settings. Collections (which can be large) will only print their size by default for example. (but I imagine you are probably planning to do that anyway)

Done.

[lahodaj]

FWIW, in VSCode, this needs to be enabled explicitly using the:

"debug.inlineValues": "on"

setting. I didn't find a way, yet, to make it work with auto.

[mbien]

gave it another try and it worked great. I got one exception once but wasn't able to reproduce it a second time:

java.lang.NullPointerException: Cannot invoke "com.sun.source.util.TreePath.getLeaf()" because "path" is null
	at com.sun.source.util.TreePathScanner.scan(TreePathScanner.java:66)
	at org.netbeans.modules.debugger.jpda.ui.values.ComputeInlineValues.computeVariables(ComputeInlineValues.java:115)
	at org.netbeans.modules.debugger.jpda.ui.models.InlineValueComputerImpl$ComputeInlineVariablesFactory$1.run(InlineValueComputerImpl.java:344)
	at org.netbeans.modules.debugger.jpda.ui.models.InlineValueComputerImpl$ComputeInlineVariablesFactory$1.run(InlineValueComputerImpl.java:321)
[catch] at org.netbeans.modules.java.source.JavaSourceAccessor$CancelableTaskWrapper.run(JavaSourceAccessor.java:273)
	at org.netbeans.modules.parsing.impl.TaskProcessor.callParserResultTask(TaskProcessor.java:561)
	at org.netbeans.modules.parsing.impl.TaskProcessor$RequestPerformer.run(TaskProcessor.java:786)
	at org.openide.util.lookup.Lookups.executeWith(Lookups.java:288)
	at org.netbeans.modules.parsing.impl.TaskProcessor$RequestPerformer.execute(TaskProcessor.java:702)
	at org.netbeans.modules.parsing.impl.TaskProcessor$CompilationJob.run(TaskProcessor.java:663)
	at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:572)
	at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:317)
	at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:1403)
	at org.netbeans.modules.openide.util.GlobalLookup.execute(GlobalLookup.java:45)
	at org.openide.util.lookup.Lookups.executeWith(Lookups.java:287)
	at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:2018)

the inline hint should also listen to the main on/off toggle and be potentially also configurable like its other friends (see options window):

(I think listening to the main toggle would be sufficient, finer grained options could be added when needed in followup PRs - we don't have to solve everything at once)

[lahodaj]

Thanks for testing. I'll look at the exception.

For the toggle - I think I would prefer to have a different toggle (people may want the debugger values, but not parameter hints, and maybe even vice versa). I'll look into that.

[neilcsmith-net]

I like where this is going, and agree that this shouldn't be aligned with the inline hints toggle but something separately configured.

[mbien]

What I had in mind is that I think it would be nice to retain the master switch for all inline hints, but add more shortcuts for the sub-switches. It could be somewhere in the debugger toolbar too potentially. Completely decoupled from the editor setting could also work - not sure what is more intuitive. (I suppose i could double-bind my mouse button to achieve something like a master switch still no matter how its implemented)

[neilcsmith-net]

Aside from commit cleanup (cause of failing test) is this close to ready for merging, or are we retargetting for NB27?

[lahodaj]

Moving to NB 27, although assuming I can stabilize tests, I would like to integrate as early as possible (so that there's time to fix any breakages).